Activating Objects and Controlling Object Lifetime

Depending on how .NET Remoting objects are instantiated, they are said to be either server-activated or client-activated objects. This section describes the differences. It also discusses how to control object lifetime.

Server Activation

The lifetime of a server-activated object is controlled by the server. Although the object is instantiated by client-side code, this client call creates only the proxy object in the caller’s process. The server-side object, which is ultimately responsible for executing code to complete a method call, is not created on the server until the client makes a method call on the object. This avoids a round-trip to the server when the client instantiates the object and also avoids tying up server resources until they’re needed. A drawback to server activation is that only the default constructor (the constructor method that takes no arguments) is available for the object using basic .NET Remoting. Server-activated objects must be registered with the .NET Remoting infrastructure. When you do this, specify one of two WellKnownObjectMode values: either SingleCall or Singleton.

A SingleCall object exists only long enough to service a single method call from the client. A new object instance will be created for each subsequent method call or for additional callers. Any instance data that is passed to the object to complete the method call is destroyed along with the object. SingleCall objects are considered stateless.

An instance of a Singleton object can remain active on the server for many method calls and can service calls for many callers. Only one instance of a Singleton object is present at any time. When values are assigned to a Singleton object’s properties then those same property values are available to all callers. This type of object is useful for maintaining application-wide state information when all callers should access the same data. Later in the chapter, Exercise 3.4 demonstrates this. The lifetime of a Singleton object can last as long as the host application is running, or you can use lifetime lease settings to control when an instance is destroyed and a new instance will be started to serve new requests. Lifetime leases are discussed in a later section of this chapter, “Controlling Object Lifetimes.”

The following code snippet shows how to register a server-activated object in the host application:

RemotingConfiguration.RegisterWellKnownServiceType( _    GetType(RemoteObjectClass), "MyUri", _    WellKnownObjectMode.SingleCall)

Notice the arguments that are passed to the RegisterWellKnownServiceType method. First we use GetType to expose information (the metatdata or class definition) about the remote class. Then we specify a unique string to identify our object to the .NET Remoting infrastructure. (This is called a Unique Resource Identifier, or URI. In this example, we are simply using the string MyUri.) Finally we specify whether the object should be a SingleCall or Singleton. The preceding code shows registration of a SingleCall type of object.

Client Activation

The client directly controls the lifetime of a client-activated object. This can be useful when the client may want to keep an object activated and maintain its state information over multiple method calls. When the client code instantiates the object, a round-trip to the server occurs, the object is created on the server, and a proxy object is created on the client. The object will remain available on the server for calls from the same caller. If the calling client creates two instances of the remote object, two objects will be created on the server.

Your client code will use the following code to instantiate the object:

Dim MyRemoteClass As RemoteObjectClass = _    CType( _       Activator.GetObject(_          GetType(RemoteObjectClass), _          "http://localhost:8088/MyUri"), _          RemoteObjectClass) 

Notice that we are using the System.Activator class. The GetObject method creates a proxy for the remote object. We are passing three parameters to the GetObject method: a reference to the type information for the object that we want to create; the URL, which is a string that indicates where the remote server can be located on the network; and the class name. Later in this chapter, you will see some alternative ways to instantiate objects by using configuration files.

Controlling Object Lifetimes

The amount of time that a marshal-by-reference object remains in memory is determined by properties of its lifetime lease. After an object’s lease time has expired, the lease manager, running in the server application domain, marks the object as available for garbage collection. (The lease manager is part of the .NET Remoting infrastructure.) A lease object associated with the marshal-by-reference object is created when the object is activated by a client. Lease object properties can be set at the time of initialization. Some lease properties are shown in Table 3.1. A client can also request to renew an object’s lease time if they wish to continue using it.

Table 3.1: Important Properties of the Lease Object

Property	Description
InitialLeaseTime	This property can be set only at initialization. The default setting is 5 minutes. A setting of zero indicates that the object should have an infinite lifetime and will remain active in memory until the host process is shut down.
CurrentLeaseTime	This property shows the amount of time left until the lease will expire. This property can be changed by a call to renew the lease.
RenewOnCallTime	This property sets the amount of time that the initial lease time is extended after each client call on the object. The default setting is 2 minutes.

Remember that server objects that are marshaled by reference must always inherit from the .NET Framework class MarshalByRefObject. To set the lease properties, you must override the InitializeLifetimeService method of MarshalByRefObject. The code in Listing 3.3 shows an example of this. Notice that the code calls the constructor in the parent class and then checks the CurrentState property to make sure that the calls to change the other property settings will be allowed.

Listing 3.3: Overriding MarshalByRefObject.InitializeLifetimeService

Public Class MyLifetimeControlObject    Inherits MarshalByRefObject        Public Overrides Function InitializeLifetimeService() As Object       Dim lease As ILease = CType(MyBase.InitializeLifetimeService(), ILease)       If lease.CurrentState = LeaseState.Initial Then          lease.InitialLeaseTime = TimeSpan.FromMinutes(1)          lease.RenewOnCallTime = TimeSpan.FromSeconds(2)       End If       Return lease    End Function  End Class 

As you can see, the RenewOnCallTime property shows that each client call to an object extends its lifetime. Sometimes, however, you might want to explicitly extend an object’s lease time. The following code snippet shows how to get a reference to the object’s lease by calling RemotingServices.GetLifetimeService and then calling the lease’s Renew method:

Dim obj As New RemoteType() Dim lease As ILease = CType( _    RemotingServices.GetLifetimeService(obj), ILease) Dim expireTime As TimeSpan = lease.Renew( _    TimeSpan.FromSeconds(20))

Note 

The TimeSpan object is a class in the System namespace that can be used to specify a period of time. The preceding examples use the TimeSpan.FromSeconds and TimeSpan.FromMinutes methods as a standardized way to pass a value representing a time period to the lease.Renew method and to set the lease properties.