Remoting lifetime for static objects in app domain with client activated objects

Question

I'm curious about shared/static object lifetime in an AppDomain where the RemotingCalls are the cause of creating the shared objects.

We're using a Remoting setup that uses client activated objects of wich we only use the functions to reach into the server. The remoting objects are setup as singletons.

The server setups a channel and uses RemotingConfiguration.Configure to load a configuration file.

Some of these server functions touch and use some static (shared in vb.net) variables on the server. I can't find out what the lifetime of these static variables is, they get created (static constructor is run) when they're touched for the first time. Using logging I can't see the objects dispose/finalize happen.

Waiting for a couple of minutes after connecting to the remoting server sees the shared objects alive and well.

The question:

So what is the expected live time of static objects in this remoting setup. Do they live as long as the AppDomain or do they get cycled out when the Remoting objects get swapped. And what is the correct way to extend their lifetime if needed?

The answer:

Static types live in AppDomain since they accessed the first time till AppDomain is unloaded. So you don't need to extend their lifetime as long as AppDomain is running.

Answer 1

Static fields are never garbage-collected. Take a look at Jeffrey Richter's article.
Static fields are considered as a root by Garbage Collector, so Garbage Collector will always assume that static fields are used.

Static fields are initialized when owner type is loaded. JIT compiler loads type on when it needs to build a method and sees reference to this type. Once loaded, the type stays there for all AppDomain lifespan, hence anything referenced by the fields that belong to the type (static fields) will be considered as used references and will not be garbage collected.

Also, regarding this statement:

I can't find out what the lifetime of these static variables is, they get created (static constructor is run) when they're touched for the first time.

Technically static variable aren't necessarily 'touched' the first time in static constructor. Consider class like this:

public static class Test
{
    private static MyType myType;

    static Test()
    {
        myType = new MyType();
    }
}

Static constructor (type constructor) will not be ever called, unless you have the code that is executing and referencing this type like var x = Test.myType;. Well, this probably depends on what 'touched' exactly means.

The answer:

Static types live in AppDomain since they accessed the first time till AppDomain is unloaded. So you don't need to extend their lifetime as long as AppDomain is running.

Answer 2

Remoting objects are not garbage collected until after the lease expires - the lease protects them from the GC as there is no obvious visible reference to them. The default lease period is 5 minutes, the garbage collector may run in another couple of minutes (depending on load, memory usage, etc.) and then the last reference to your object should be gone. Only after all this has happened, an instance object should be collected on the next GC run. Static objects, however, won't be garbage collected at all.

As for the second part of the question, the correct way of extending the lifetime is called "sponsorship" - basically when the lease expires, the server asks the clients if anyone is willing to continue using this object. There's a pretty detailed article on the subject here. Don't just set the lifetime to infinity.