Lifetime Management

The lifetime of COM objects was managed by reference counting. In Chapter 2, I discussed the advantages and disadvantages of that approach and the decision of the .NET Framework designers to switch to a garbage-collected algorithm. But the garbage collector doesn’t work across process or machine boundaries. DCOM used a pinging algorithm to detect clients that had terminated without releasing their reference count, but this mechanism didn’t work well through network proxies or firewalls. Sometimes the server can make calls back to the client, and sometimes it can’t. We need a mechanism for managing the lifetime of remoting objects that works with garbage collection and works with the Internet environment in which we often need to run.

Remoting object lifetime management is a difficult problem to solve.

Remoting object lifetime is managed with a timed object called a lease. When the remoting infrastructure creates an object on the host, the object is given a new lease, containing a property called time to live (TTL). The system default is 5 minutes, but the interval is configurable, as I will demonstrate. Periodically (default, every 10 seconds), the runtime infrastructure’s lease manager checks to see whether the object’s TTL has expired. If it has, the lease manager lets go of all server-side connections to the object, thereby allowing it to become garbage and be swept up in the next collection.

Remoting object lifetime is managed through a timed lease.

“But wait,” you say. “I’m using that object. Don’t sweep it up!” You certainly don’t want an object dying under you if you’re still using it. The more heavily used an object is, the more likely it is to be used in the future. So every time a client makes a call on a remoting object, the lease manager adds an amount of time to its TTL. The default is 2 minutes per call, but that interval is also configurable.

Every call you make to an object automatically extends its TTL.

The default values for lease-related time intervals are well chosen for development environments, keeping in mind the Principle of Least Astonishment. The intervals are long enough that objects don’t suddenly disappear while you’re developing them, and they’re short enough that they don’t balloon completely out of control either. These settings will be too long or too short for almost every production application, too long in the case of computer clients and too short in the case of human users. You can set them in the host’s configuration file, shown in Listing 10-8. These settings affect all objects on the server, which is often what you want. If you want to vary it by class or individual object, you must override the InitializeLifetimeService method of MarshalByRefObject and have it return a lease containing the values that you want (not shown).

Default lease times can be overridden in configuration files or code.

Listing 10-8: Lifetime lease management overriding in a configuration file.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <lifetime leaseTime = "30S"  renewOnCallTime="30S"  sponsorshipTimeOut="30S" />  [other items omitted] </application> </system.runtime.remoting> </configuration>

“But even this is too blunt,” you wail. “I don’t know at development time, or even administration time, what I want my objects’ lifetimes to be. I need to be able to control individual objects’ lifetimes at run time.” The remoting infrastructure contains a solution to this need as well. When you create a remoting object (actually any time thereafter, but they’re usually done very soon after creation), you can add a sponsor to a lease, as shown in Listing 10-9.

You can keep a remoting object alive with a lease sponsor object.

Listing 10-9: Setting up a lease sponsor.

Public Sub MyOwnAddSponsor() ’ Get our current lease object Dim lease As Runtime.Remoting.Lifetime.ILease lease = Me.GetLifetimeService() ’ Make a new object of our sponsor class. Add it to the ’ list in the lease. lease.Register(New MyOwnSponsor) End Sub 

A sponsor is a remotable (derived from MarshalByRefObject) object that implements the ISponsor interface. When the lifetime manager determines that an object’s TTL has expired, it goes to each registered sponsor and calls the method ISponsor:Renewal, asking the sponsor if it wants to extend the lease. The sponsor replies by returning a time span, specifying how much more additional time (if any) to grant the object, as shown in Listing 10-10. This way, if you know that your object is waiting around for something important but also lengthy and indeterminate, such as human user input, you can make the remoting infrastructure keep it around. If the sponsor doesn’t respond within a configurable amount of time, it forfeits its opportunity to extend the lifetime.

Listing 10-10: Sample lease sponsor.

Public Class MyOwnSponsor Inherits MarshalByRefObject Implements Runtime.Remoting.Lifetime.ISponsor ’ Remoting runtime infrastructure calls this method when it ’ notices that our remoting object’s lease time-to-live has ’ expired. Public Function Renewal(ByVal lease As _ System.Runtime.Remoting.Lifetime.ILease) As _ System.TimeSpan Implements _ System.Runtime.Remoting.Lifetime.ISponsor.Renewal ’ Ask user if he wants to renew the lease. If yes, return the ’ amount of time to renew it for. If (MessageBox.Show("Renew lease for another 30 seconds?", _   "Sponsor", MessageBoxButtons.YesNo) = DialogResult.Yes) Then Return TimeSpan.FromSeconds(30) Else Return TimeSpan.Zero End If End Function End Class

A sponsor can also live on the client, thereby allowing the client to ensure that its object is going to stay around long enough to, say, service a human user. However, for this to work, the server must be able to make remoting calls into the client and must have the Infrastructure security permission. Sometimes these conditions aren’t possible because of firewalls or other configuration issues. In that case, your object can provide a heartbeat method for a client to call to keep it alive.

A lease sponsor can live on the client as well as the server.

I’ve provided a sample program for demonstrating remoting object lifetime management, which you’ll find in the directory \Lifetime. The client is shown in Figure 10-8. The defaults have been set to 30 seconds for this example. If you create a client-activated object and then make a call on it 45 seconds later, you’ll get an exception that says the object’s lease has expired and it has been dumped. In the case of single-call objects, you don’t greatly care because they get dumped after every call anyway.

I’ve provided a sample program for demonstrating remoting object lifetime management.

Figure 10-8: Lifetime sample program.

What’s less obvious is that the lease lifetimes apply to singleton objects as well as client-activated objects. Try running one instance of the client and setting the property on the singleton object. Run another instance immediately, and you’ll see the state set by the first object. Then run another instance 60 seconds later. You’ll see that the first instance of the singleton has timed out and that you are using a second instance. The state set by the first client has been dumped. Because singletons are used most often to share state among a number of clients, this behavior might be disconcerting. You need to think about this in advance. The easiest way to maintain the state of the singleton object is for the object to set its lifetime to infinite by returning TimeSpan.Zero.

Lease lifetime applies to singleton objects too.

Remoting objects will not become garbage until their leases expire. This will generally be a longer time than they would have lasted had they been local objects. If your remoting object contains scarce resources, you may have to provide a deterministic finalization method to release those resources.

You might have to provide a deterministic finalization method to release scarce resources held by a remoting object.

Tips from the Trenches

Although the timed and sponsored mechanism might feel cumbersome, it was the best Microsoft could do in this situation because they needed an architecture that would work if the server couldn’t call back into the client, as well as if it could.