In developing objects, whether they are standard COM objects or COM objects enhanced to work better with MTS,an object can be one of two types. The two types are stateless and stateful. A stateless object does not retain any information from one method call to the next. A stateful object has some internal storage mechanism that allows it to retain information between two separate method calls.
An application designer can take advantage of either type of component in their applications. The two types of components can even be mixed in one application. There may be times that it is more efficient from a coding standpoint to develop a component that holds state within the object. However, there are tradeoffs in using stateful components within the context of MTS.
As we discussed earlier in this chapter, MTS can manage the creation and utilization of components automatically. This allows applications to scale much more efficiently than using other means. To look at the effect that state has on this mechanism, we need to look at the deactivation of objects.
An object has two modes inside of MTS. When it is first created, it is deactivated. A deactivated object looks to the client as a real object, but it consumes very few resources on the server. Through a process known as just-in-time activation, MTS will activate the component when the client actually calls a method on the object. This allows the clients to not have to worry about when it should create an instance of an object in relation to when it is used. The client can create the instance and hold it as long as it wants before using it, as MTS will not create and activate the object until it is needed. This is similar in the ASP world to using the
tag to create an object instance rather than <OBJECT>
.Server.CreateObject
There are three ways that an object, once activated, can be deactivated. Deactivating an object is different from destroying it. The object can request deactivation through the
interface by calling either ObjectContext
or SetComplete
. If the object is participating in a transaction, and that transaction is committed or aborted, then the object will be deactivated once all of the processing in the transaction is completed.. Finally, if all of the clients that are accessing the object release their references to that object, then it will be deactivated. When an object is deactivated, MTS can use the resources that were allocated to it for other objects. This means that any information that was stored inside of the object is lost. The recently deactivated object could also be recycled if MTS detects another client requesting the same object.SetAbort
A stateful object is one that retains internal information from one method call to another. For an object to be able to do this, there are certain tradeoffs that must be made. MTS gains its efficiency from being able to automatically activate and then quickly deactivate objects. As we said earlier, when an object deactivates, it loses all information that is stored inside of it. In order for an object to be stateful, it must maintain internal information, which means it cannot be deactivated. If a stateful object were to be deactivated, it would lose all of its state, thus becoming a stateless object.
When an object decides to become stateful, MTS no longer has the ability to use its resources for any other objects. An object will become "stateful" if it does not call
or SetComplete
when it finishes its processing. The stateful object has in effect locked a portion of the resources that MTS has to work with. MTS relies on its ability to dynamically manage resources in order to allow applications to effectively scale. Therefore, if a system is using a large number of stateful objects, then it will be much less efficient when scaling.SetAbort
This does not mean to say that you should never use stateful objects when developing MTS applications. As we stated earlier, the use of stateful objects can make the development of client applications much easier. It is just important for the developer to understand the implications that using stateful objects will have on the scalability of their application.