DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
Which Resource managers are supported?
At the time of writing, MTS only supported MS SQL Server and Oracle, although Microsoft stated that support for MTS had been announced by IBM and that MTS was currently running against DB2 at IBMs labs in Toronto. They also stated that they were working with Informix. Over time, I expect support to be extended to all the XA-compliant DBMSs currently available along with other Resource managers such as MQSeries. MSMQ queues can also be placed under transaction control. A local enqueue or dequeue of a message can be part of a transaction.
It should be remembered that because the XA implementations available from each vendor are different (because they were based on a specification), they will all need to be tested separatelythus the uncertain nature of the support and the need for combined lab testing. Longer term, the team working on Transaction server aim to provide support for many other Resource managersOODBMSs, transaction file systems, queues, and workflow files. One small point. If ODBC and Oracle are being used, the developer needs to change the ODBC Driver to the Microsoft-supplied driver that supports the new protocol.
MTS in operation
Microsofts Transaction servers model assumes no programming of the start transaction or end transaction commands. Instead, each component is declared to be transactional or not using Transaction Server Explorerthe administration tool.
Applications written in Visual Basic cannot initiate transactions directly. Instead, the application must invoke an object which then invokes the transactionthis could be in a three-tier architecture. In practice, Transaction Server is probably best used within a three-tier architecture, where client calls business logic server (the controlling transactional object/component), which in turn makes calls to the data sources.
When a Resource manager is loaded, it contacts the Transaction manager to declare its presence. The application/component begins the transaction by calling the Transaction managers BeginTransaction method. This creates a transaction object that represents the transaction. The application then calls Resource managers to do the work of the transaction.
The applications calls to each Resource manager identify the applications current transaction, that is, the transaction object. Thereafter, all calls are associated with the transaction object until the transaction is ended. This is like giving the transaction a unique identifier.
The Resource managers enlist in the transaction by calling the Transaction manager as the transaction progresses. The Transaction manager keeps track of each Resource manager and its actions. The Resource manager then performs the transaction requests on behalf of the application, but instead of updating the resource (DBMS, for example) it keeps the updates in a log as we saw earlier in the general description, awaiting further instructions from the Transaction manager.
The application then completes the transaction by calling the COMMIT method on the Transaction manager or alternatively, if it is unable to complete the transaction, by using the ABORT method. The abort command causes the Transaction manager to contact each Resource manager, which is then instructed to discard all updates in waiting for that transaction.
If the application itself fails before completing, the Transaction manager will abort the transaction on behalf of the application. Similarly, if any Resource managers have failed, the Transaction manager stores the abort command and forces an abort once the Resource managers are again active.
Once the application has issued the commit command, however, the Transaction manager takes over and controls the update via the two-phase commit protocol.
Phase 1-The Transaction manager issues the command to each Resource manager to prepare to commit.
Phase 2-If all Resource managers confirm they can commit, the commit message is broadcast to each Resource manager by the Transaction manager.
The Transaction manager thus keeps its own log of transactions so that it can coordinate with Resource managers over in-doubt transactions. This log is disk based and sequential. The Transaction manager records transactions, starts, enlistments, and commit decisions in the log. During normal processing, the Transaction manager only writes to the log. If the Transaction manager itself fails, it is able to reconstruct the transactions most recent state by reading the log.
When commit trees exist, the Transaction managers cooperate to determine the status of in-doubt transactions, and each Transaction manager on each node is then responsible for handling the transactions on its node. Thus each Transaction manager uses the log to handle both the transactions where it was the coordinator and incoming and outgoing transactions.
Previous | Table of Contents | Next |