.NET Reference Guide

Remoting: Lifetimes and Leases

Last updated Jul 29, 2005.

An object's lifetime is the total amount of time that it spends in memory. In .NET, all remote objects, whether they're server activated or client activated, have a default lifetime. Server activated single call objects, of course, are destroyed after satisfying a single client request. Singleton objects and client activated objects persist for a period of time. The server application domain controls the lifetime of a remote object. It is instructive to understand why this is so.

If you're familiar with COM and DCOM, you will remember that an object would remain in memory as long as a client maintained a reference to it. This worked well in simple scenarios, but in complex applications the reference counting was quite involved and objects tended to be destroyed prematurely because the reference count unexpectedly went to 0, or left in memory indefinitely because the reference count was not decremented correctly. In addition, constant pinging between client and server resulted in high network traffic volumes. In short, reference counting is difficult to implement and therefore unreliable, and uses a lot of network bandwidth.

In a distributed application, it's important to have some method of automatically destroying an object on the server and reclaiming its memory. Otherwise, unexpected disconnections and improper programming on the client can cause server objects to remain in memory indefinitely, using valuable resources and eventually leading to a system crash.

In .NET, the server controls a remote object's lifetime using a combination of leases, a lease manager, and some number of sponsors.