Remote lifetime for static objects in the application domain with client-activated objects

Question

I am wondering what is the lifetime in a shared / static object in AppDomain, where RemotingCalls are the reason for creating shared objects.

We use the Remoting setting, which uses objects activated by the client, which we use only to access the server. Remote objects are set as single objects.

The server configures the channel and uses RemotingConfiguration.Configure to load the configuration file.

Some of these server functions relate to 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 are created (the static constructor starts) when they are touched for the first time. Using Logging I don't see dispose / finalize objects happen.

Waiting for several minutes after connecting to a remote server sees shared and live objects.

Question:

So, what is the expected lifetime of static objects in this remote setup. They live until the AppDomain or they go out on the bike when Remoting objects are exchanged. And what is the right way to extend their life if necessary?

Answer:

Static types live in AppDomain since they first loaded until the AppDomain is unloaded. Thus, you do not need to extend the life of the device while the AppDomain is running.

Answer 1

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

Static fields are initialized when the owner type is loaded. The JIT compiler loads a type when it needs to build a method and sees a link to that type. After loading, the type remains there for all AppDomain life cycles, so all links related to the type (static fields) will be considered as used links and will not be garbage collected.

In addition, with respect to this statement:

I can’t find out how long these static variables live, they get (the static constructor starts) when they touch the first time.

Technically, a static variable is not necessarily “affected” for the first time in a static constructor. Consider the class as follows:

public static class Test { private static MyType myType; static Test() { myType = new MyType(); } } 

A static constructor (type constructor) will never be called unless you have code that executes and references this type, for example var x = Test.myType; . Well, that probably depends on what exactly “touched” that is.

Answer:

Static types live in AppDomain since they first loaded until the AppDomain is unloaded. Thus, you do not need to extend the life of the device while the AppDomain is running.

Answer 2

Remote objects are not collected with garbage until the lease expires - the lease protects them from the GC, since there is no obvious visible link to them. The default rental period is 5 minutes, the garbage collector can work after another couple of minutes (depending on the load, memory usage, etc.), and then the last link to your object should disappear. Only after all this has happened, the instance object should be assembled in the next start of the GC. Static objects, however, will not collect garbage at all.

As for the second part of the question, the correct way to extend the life of the service is called “sponsorship” - basically, when the lease expires, the server asks clients if anyone wants to continue using this object. There's a pretty detailed article on the topic here . Do not just set the life time to infinity.