DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Triggering

In the basic DCOM approach the client has control over the object lifetime; client references are bound to the same object instance for as long as the reference is valid. But Transaction Server incorporates a process called “just in time” activation.

During method execution, a Transaction Server object can use the SetComplete and SetAbort methods to indicate that the object does not need to maintain state after returning the call.

As a result, the Transaction Server can deactivate the object when returning back to the client. The object remains deactivated until the client makes another call to the object. Only when the object is subsequently called is it reactivated, at which time it reacquires the resources it needs to service the call. From the client’s point of view, it thinks it holds the object all the time; in reality it is activated and deactivated many times. Why do this?

As long as the object is deactivated, only limited server resources need to be allocated to it—those required to maintain object context and its association with client references. Other server resources, such as memory for the object’s private data, do not need to be allocated to the object and can be used for other purposes. The purpose of this service of MTS is thus to make more efficient use of resources—again, a feature essential in a transaction processing system.

Support for Asynchronous Processing

Normal communication between clients and servers using DCOM is synchronous, with the client sending a request and then waiting with its thread blocked until the reply is received. We saw in an earlier chapter that there were ways in which asynchronous communication can be supported indirectly:

  By using threads-The client can spawn a new thread to handle any additional processing while the existing thread waits for the reply.
  By using the outgoing interface-All events sent to outgoing interfaces are by their nature asynchronous, as the event is sent to DCOM and server processing can then proceed.
  By using a call back object-In this case a special call back object is created to handle any replies.
  By using MSMQ-When the client sends a message, the message is placed first on the local transmission queue. Once the acknowledgment of receipt has been given, the client can proceed, acting asynchronously.

MTS, however, provides direct support for asynchronous processing. A client can issue a number of calls to the various servers under transaction control and not block processing; all the calls can be executed in parallel. Why is this important?

Support for asynchronous processing is absolutely essential in a distributed transaction processing application—not for the end user client part of the application particularly, but the “business logic” transaction part of the application. Let us use an example:

Suppose clients accessed a server process that performed some business transaction that updated three DBMSs and also invoked two components.


Figure 13.4  Example of three-tier application with distributed updates

If no support was available for asynchronous processing, the transaction would need to pass the updates to DBMS1 and then wait for a reply. Once the reply had been received, it would then send the updates to DBMS2, then wait for a reply. Once that reply had been received, it would send the updates to DBMS3, then wait for its reply. After this reply had been received, it would invoke component 1 and wait for the reply. Once the reply had been received, it would then invoke component 2 and wait for the reply. Once it had replied, it would then do the rounds again to see if the DBMSs were ready to commit, and so on.

The processing would probably take as long as it has taken you to read the previous paragraph—if not longer—hardly the sort of high performance you want in a transaction processing application. By supporting asynchronous processing, all these calls can be executing in parallel; processing time is probably reduced by a fifth in comparison with the equivalent time when synchronous processing is used. Support for asynchronous processing is thus key as a service and actually of real use in other sorts of applications—not just transaction processing ones.


Previous Table of Contents Next