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 IBM’s 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 separately—thus 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 managers—OODBMSs, 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

Microsoft’s Transaction server’s 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 Explorer—the administration tool.

Applications written in Visual Basic cannot initiate transactions directly. Instead, the application must invoke an object which then invokes the transaction—this 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 manager’s 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 application’s calls to each Resource manager identify the application’s 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.

  If all Resource managers reply that they can commit, processing proceeds to Phase 2.
  If any of the Resource managers reply that they cannot commit, the Transaction manager contacts all the Resource managers to force an abort, and instructs them to discard all updates in waiting for that transaction.
  If any of the Resource managers cannot be contacted, for example, the Resource manager itself has failed or the network has failed, those Resource managers that can be contacted are told to abort. The abort command is then stored in the Transaction manager log awaiting the restart of the Resource managers that could not be contacted. Once the Resource managers are up and running again, the abort is forced.

Phase 2-If all Resource managers confirm they can commit, the commit message is broadcast to each Resource manager by the Transaction manager.

  If all the Resource managers are still active, they commit the updates.
  If any of the Resource managers fail to respond, it could be for two reasons—either a communication failure or because the Resource manager has failed.
  If there is a communication line failure, the commit or abort notification may not arrive for minutes, even hours. During this period the Resource manager is termed to be “in doubt” about the outcome. But it will keep locks on the data until notification is received. Once the line is up and running the Transaction manager will commit the transaction. Although not advisable normally, the administrator can abort in-doubt transactions manually from his console if they are tying up the system.
  If the Resource manager fails and then restarts, the Resource manager must reconstruct the committed state of the resources it manages. If it does fail, all of its enlisted transactions are aborted, except those that prepared or committed prior to failure. When the Resource manager restarts, it asks the Transaction manager about the outcome of the “in-doubt” transactions in which it enlisted. The Transaction manager then tells the Resource manager the outcome of each in-doubt transaction, and the Resource manager commits or aborts accordingly.

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 transaction’s 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