DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
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 clients 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 itthose required to maintain object context and its association with client references. Other server resources, such as memory for the objects 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 resourcesagain, a feature essential in a transaction processing system.
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:
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 applicationnot 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 paragraphif not longerhardly 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 applicationsnot just transaction processing ones.
Previous | Table of Contents | Next |