MTS extends COM to allow object deactivation, even while client references are maintained. This makes server applications more scalable by allowing server resources to be used more efficiently.
MTS objects are initially created in the deactivated state. When a client invokes a method on an object that is in a deactivated state, MTS automatically activates the object. During activation, the object is put into its initial state.
Note For Visual C++ developers, calls to QueryInterface, AddRef, or Release do not cause activation.
This ability for an object to be deactivated and reactivated while clients hold references to it is called just-in-time activation. From the client's perspective, only a single instance of the object exists from the time the client creates it to the time it is finally released. In actuality, it is possible that the object has been deactivated and reactivated many times.
Just-in-time activation
The context object exists for the entire lifetime of its MTS object, even across one or more deactivation and reactivation cycles.
Object deactivation allows clients to hold references for long periods of time with limited consumption of server resources. Consider, for example, a client application that spends 99 percent of its time between transactions. In this case, the MTS objects are activated less than 1 percent of the time.
When is an object deactivated?
An MTS object is deactivated when any of the following occurs:
An object can request deactivation by using the IObjectContext interface. You can use the SetComplete method to indicate that the object has successfully completed its work and that the internal object state doesn't need to be retained for the next call from the client. Similarly, SetAbort indicates that the object cannot successfully complete its work and that its state does not need to be retained.
You can develop stateless objects by using MTS objects that deactivate on return from every method.
MTS does not allow an object to maintain private state that it acquired during a transaction. When an object's transaction is committed or aborted, the object is deactivated. Of these deactivated objects, the only ones that can continue to exist are the ones that have references from clients outside the transaction. Subsequent calls to these objects reactivate them and cause them to execute in the next transaction.
This occurrence is listed here for completeness. The object is deactivated and never reactivated. The object's context is also released.
How are objects deactivated?
MTS deactivates an object by releasing all its references to the object. This causes properly developed components to destroy the object; this feature also requires the component to follow the MTS reference passing rules (see Passing Object References) and the COM reference counting rules.
Note MTS writes an Informational message to the event log when objects that do not report their reference count are deactivated.
Application components are responsible for releasing object resources on deactivation. This includes:
Doing Additional Work on Activation and Deactivation
If an object is not already activated and it supports IObjectControl, MTS calls the Activate method prior to initiating the client request. Components can use the Activate method to initialize objects. This is especially important for initialization that requires access to the context object. Here, keep in mind that the context is not available during calls to the component's class factory. Having access to the context object through Activate allows you to pass a reference to the context object to other methods; this reference can then be released in the Deactivate method. The Activate method is also useful for objects that support pooling (see Object Pooling and Recycling).
For objects that support the IObjectControl interface, MTS calls the Deactivate method when it deactivates the object. You can use this method to free resources held by the object. The Deactivate method is also useful for objects that support pooling. Like the Activate method, the Deactivate method has access to the object context.
Building Scalable Components, Stateful Components, Object Pooling and Recycling, SetComplete, SetAbort, IObjectControl