Managing MTS Transactions

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Understanding how distributed transactions work helps you effectively manage transactions for Microsoft Transaction Server (MTS) packages. This section describes how transactions work, and how to monitor and manage transactions in the MTS Explorer.

Understanding MTS Transactions

Microsoft Transaction Server (MTS) enables you to easily use, monitor, and administer distributed transactions in your applications. A distributed transaction is a transaction involving updates to transaction-protected resources on more than one system. The MTS transaction manager, Microsoft Distributed Transaction Coordinator (MS DTC), provides a distributed transaction facility for Windows NT® and Windows® 95 systems. MS DTC also makes it possible to update two or more transaction-protected resources on a single system.

Managing MS DTC

In order to manage transactions, you must first start Microsoft® Distributed Transaction Coordinator (MS DTC). If you have not started MS DTC on your MTS server, clients cannot access the transactional packages that you are managing.

To configure and run MS DTC clients on a Windows NT machine, the user must have write access to the local registry and remote read access to the server's Software\Classes key.

To start or stop MS DTC:

In the right pane of the MTS Explorer, select the computer on which you are managing transactional packages.
Open the Action menu and select Start MS DTC or Stop MS DTC. You can also right-click and select Start MS DTC or Stop MS DTC in the right-click menu.

By default, the Microsoft Distributed Transaction Coordinator (MS DTC) is configured to start automatically when a Windows NT or Windows 95 system starts. To prevent MS DTC from automatically starting after rebooting a Windows 95 computer, use the registry editor to find the HKEY_LOCAL_MACHINE \Software \Microsoft \Windows \CurrentVersion \RunServices registry key and then delete the value entry named MSDTC. If you want to enable automatic startup of MS DTC again, use the registry editor to create a value entry named MSDTC with the string value "msdtcw -start" under the HKEY_LOCAL_MACHINE \Software \Microsoft \Windows \CurrentVersion \RunServices registry key.

Starting and Stopping MS DTC on Clustered Servers

On a clustered server, you can start and stop MS DTC by either using the MTS Explorer or using the MSCS administrative utility. Using the "net start msdtc" or "net stop msdtc" command does not work. To start and stop MS DTC on an MSCS cluster from the command line, use "msdtc -start" and "msdtc -stop", respectively.

You can also configure DTC settings, such as the location and size of the DTC log file, using the Advanced tab of the Computer property sheets.

To configure MS DTC settings:

In the right pane of the MTS Explorer, select the computer on which you are managing transactional packages.
Open the Action menu and select Properties. You can also right-click and select the Properties option from the right-click menu.
Select the Advanced tab. You can adjust how transactions are displayed in the Transaction List and Trace Message windows. You can also change the location or size of the MS DTC log. Increasing the size of the MS DTC log lets you run more concurrent transactions.

Important: MS DTC has an upper limit on the size of the log file:

On Windows NT, the maximum log size is 512 MB.
On Windows 95, the maximum log size is 64 MB.

Compressing the MS DTC Log File

The MS DTC log file can be located in a compressed directory. However, for optimum performance, do not compress the Microsoft DTC log file or store it in a compressed directory. MS DTC must decompress the log file before it can be used.

Removing DTCXATM.LOG Files

Before upgrading your installation of MTS 2.0, delete the DTCXATM.LOG file. Note that you must stop the MS DTC service before deleting DTCXATM.LOG.

Security and Communication Between Remote MS DTC Computers

If your application performs transactions spanning two or more computers, you must ensure that the MS DTCs on these computers are configured to communicate with each other. MS DTC runs under the identity of the System account by default. The MS DTC on one computer can communicate with the MS DTC on another computer, only if the Guest accounts on both computers are enabled. If you disable the Guest account on either machine or in the Windows NT domain to which they belong, you must configure MS DTC to run under some other user name that can communicate with the remote computer.

Note: Customers who use MS DTC in an Microsoft Cluster Server (MSCS) environment should install Windows NT QFE 116844. This QFE fixes a Remote Procedure Call (RPC) problem that can cause an MS DTC client to hang when attempting to connect to MS DTC on a clustered server. This fix is also part of Windows NT QFE1, available at the Windows NT Option Pack Web download site.

Monitoring MTS Transactions

You can administer transactions in MTS applications by using the transaction windows in the MTS Explorer. The Trace Message, Transaction Statistics, and Transaction List windows provide valuable information about the status of transactions managed by the Microsoft Distributed Transaction Coordinator (MS DTC).

Note: Transactions are automatically aborted if the transaction does not complete within the default timeout of 60 seconds. You can modify the transaction timeout by modifying the Options tab for My Computer.

You can use the Transaction List window to resolve transaction states. For more information, see the Resolving MTS Transactions topic.

To monitor transactions using the Transaction List

In the left pane of the MTS Explorer, select the computer that is hosting the transactions.
Double-click the Transaction List icon.
Right-click anywhere in the right pane, and point to the View command on the shortcut menu.

On the View submenu, click one of the following:
- Large Icon
  
  Displays transactions as large icons.
- Small Icon
  
  Displays transactions as small icons.
- Properties
  
  Lists transactions in a single column and provides a column that contains the unit-of-work ID associated with each transaction. This is the transaction's global unique identifier, and is generated by MS DTC when the transaction begins. Also listed are the parent and subordinate transactions.
- List
  
  Displays transactions sequentially in a column.

Note: The Small Icon and List commands display the most transactions at any one time. Properties provides the most information about the transactions, and Large Icon displays transactions in the most readable format.

To view transaction statistics

In the left pane of the MTS Explorer, select the computer where you want to view transaction statistics.
Double-click the Transaction Statistics icon.

To view trace messages

In the left pane of the MTS Explorer, select the computer that is hosting the transactions.
Double-click the Trace Messages icon.

The MS DTC Transaction Statistics window is displayed in the right pane.

Transaction Properties

You can view transaction properties by selecting the Properties command after right-clicking a selected transaction. The Properties command lists all transaction managers that are involved in the transaction. For a child transaction, the Properties command lists the immediate parent of transactions. If the transaction is a parent transaction, then the immediate child transaction(s) are listed.

Monitoring MTS Transactions on Windows 95

You can manage MTS transactions on Windows® 95 or Windows NT computers using the following MTS Explorer windows:

Transaction Statistics
Transaction List
Trace Message.

Note: To configure and run MS DTC clients on a Windows NT machine, the user must have write access to the local registry and remote read access to the server's Software\Classes key.

If you want to administer a Windows NT computer remotely from a Windows 95 computer, you must install the Remote Registry service for Windows 95. The Remote Registry service allows you to change registry entries for a remote Windows NT computer (given the appropriate permissions). To obtain the Remote Registry service, go to the \Admin\Nettols\Remotereg sub-directory on the Windows 95 CD. Review the Regserv.txt file for instructions on installing the Remote Registry service.

Since Windows 95 does not have an event log, MS DTC events are stored in a text file named msdtc.txt. The msdtc.txt file is located in the \MTSLogs sub-directory of the Windows directory, and contains information about MS DTC events.

When resetting the MS DTC log file on Windows 95, you may see a dialog box labeled "MTxOCI", followed by a second dialog box labeled ""Failed to create the MS DTC log file." If this occurs, you must disable automatic startup of MS DTC. Restart your computer and reset the log file. You can then re-enable automatic startup of MS DTC.

Other problems resetting the MS DTC log file can be fixed by closing the MTS Explorer, restarting MTS Explorer, and attempting the reset again. In some instances, you may have to shut down and restart the MTS Explorer several times before the MS DTC log file is fixed.

Understanding MTS Transaction States

In order to manage transactions, you must understand the different transaction states and their implications for the MTS package that you are administering. Transaction states are represented by the following icons in the Large Icon view of the Microsoft Distributed Transaction Coordinator (MS DTC) Transaction List window:

Icon	Description

	Active The transaction has been started
	Aborting The transaction is aborting. MS DTC is notifying all participants that the transaction must abort. It is not possible to change the transaction outcome at this point.
	Aborted The transaction has aborted. All participants have been notified. Once a transaction has aborted, it is immediately removed from the list of transactions in the MS DTC Transactions window. It is not possible to change the transaction outcome at this point.
	Preparing The client application has issued a commit request. MS DTC is collecting prepare responses from all participants.
	Prepared All participants have responded yes to prepare.
	In Doubt The transaction is prepared, is coordinated by a different MS DTC, and the coordinating MS DTC is inaccessible. The system administrator can force the transaction to commit or abort by right-clicking in the Transactions window and choosing the Resolve/Commit or Resolve/Abort command. Once an outcome is forced, the transaction is designated as forced commit or forced abort. Caution: Do not manually force an in-doubt transaction until you have read the Resolving MTS Transactions topic.
	Forced Commit The administrator forced the in-doubt transaction to commit (see the Resolving MTS Transactions topic).
	Forced Abort The administrator forced the in-doubt transaction to abort (see the Resolving MTS Transactions topic).
	Committing The transaction has prepared successfully and MS DTC is notifying participants that the transaction has been committed. MS DTC does not end the transaction until all participants have acknowledged receiving (and logging) the commit request. It is not possible to change the transaction outcome at this point.
	Cannot Notify Aborted MS DTC has notified all connected participants that the transaction has aborted. The only participants not notified are those that are currently inaccessible. This transaction state occurs when MS DTC must inform any resource manager (such as an IBM LU 6.2 system) that a transaction has aborted but is unable to do so because the connection to the IBM system is down. The system administrator can force MS DTC to forget the transaction by right-clicking in the Transactions window and choosing the Resolve/Forget command. Caution: Do not manually forget a transaction until you have read the Resolving MTS Transactions topic.
	Cannot Notify Committed MS DTC has notified all connected participants that the transaction has committed. The only participants not notified are those that are currently inaccessible. The system administrator can force MS DTC to forget the transaction by right-clicking in the Transactions window and choosing the Resolve/Forget command. Caution: Do not manually forget a transaction until you have read the Resolving MTS Transactions topic.
	Committed The transaction has committed and all participants have been notified. Once a transaction commits, it is immediately removed from the list of transactions in the MS DTC Transactions window. It is not possible to change the transaction outcome at this point.

Resolving MTS Transactions

If you administer MTS transactions, you may have to manually resolve a transaction for an MTS application. You can use the Transaction List window in the MTS Explorer to resolve a transaction by choosing one of the following commands:

Commit This command forces the transaction to commit.
Abort This command forces the transaction to abort and roll back to its original state.
Forget This command deletes a committed or aborted transaction from the Microsoft Distributed Transaction Coordinator (MS DTC) log. You should always force an outcome for a transaction before using this command.

Occasionally, you need to force a transaction either to commit or abort to release locks and make database resources available to other network users and applications.

This can be necessary, for example, when a communication line fails between two computers on the network. Once a transaction has been manually committed or aborted, often it is necessary also to manually force a computer to "forget" the transaction, which deletes the transaction from the local MS DTC log file.

The following illustration shows a case in which a transaction is committed manually. In this example, the following conditions are assumed:

The MS DTC on computer A is the commit coordinator.
The lines of communication along which the two-phase commit protocol is conducted proceed sequentially from computer A to computer D.
The first phase of the two-phase commit protocol has concluded, and MS DTC has written a COMMITTED record to its log.
Communication fails between computers B and C during the second phase of the two-phase commit protocol.

The transaction is left in the following unresolved state:

Because the line of communication between computers A and B is still intact, B also has committed the transaction. Both computers, however, must retain the COMMITTED records in their log files until computers C and D confirm that they also have committed the transaction. To resolve the transaction (and thereby release the database locks on computers C and D), the system administrator forces computer C to commit the transaction (see the next illustration).

Because the line of communication between computers C and D is still intact, the forced commit on computer C allows the transaction to commit on computer D. Computer D can now release its database locks and forget the transaction. Once computer D confirms to computer C that it has committed and forgotten the transaction, computer C can also release its locks and forget the transaction.

The transaction is now committed on all computers. However, because computer C cannot communicate its commit to computer B, computer B must continue to remember the transaction. Because computer B has not forgotten the transaction, computer A must also remember it. To complete the transaction, the system administrator forces computer B to forget the transaction (see the next illustration). Computer B's forced forget allows computer A also to forget the transaction. The two-phase commit protocol has been manually concluded, and the transaction is complete.

Important: Because of the outgoing-incoming communication pattern of the two-phase commit protocol, it is recommended that you manually resolve transactions on computers immediately adjacent to the break in communications. Therefore, in the preceding example, the forced commit occurs on computer C (not D), and the forced forget occurs on computer B (not A).

Generally, when systems involved in transactions are restarted and connections restored after a system or connection failure, MS DTC will automatically resolve the transactions. MS DTC cannot resolve transactions if the systems are down or connections are not reestablished. In this case, you can manually resolve transactions that are in the In Doubt, Cannot Notify Aborted, or Cannot Notify Committed state if you have a system or connection failure

In Doubt State

The in-doubt state indicates that the transaction is on a child, that MS DTC is prepared, and that the parent MS DTC is inaccessible. To resolve the in-doubt transaction, follow these steps:

Use the Transaction List window to locate the in-doubt transaction's immediate parent. To do this, right-click the transaction and select the Properties command. This displays the parent MS DTC and child MS DTC computers for the transaction.

Locate the parent MS DTC and use the Transaction List window on the parent computer to determine the outcome of the in-doubt transaction.
- If the transaction does not appear in the Transaction List window, then the transaction has been aborted, and you can abort the transaction on the child computer manually.
- If the transaction appears on the parent computer as Cannot Notify Committed, then the transaction has committed, and you can commit the transaction on the child computer manually.
- If the transaction appears on the parent computer as Cannot Notify Aborted, then the transaction has aborted, and you can abort the transaction on the child computer manually.
- If the transaction is shown as In Doubt on the parent computer, use the Transaction List window on the parent computer to locate the transaction's next immediate parent. Continue to follow the transaction up the commit tree until you locate the parent on which the transaction is either not shown (indicating that it aborted), in the Cannot Notify Aborted (indicating that it aborted) state, or in the Cannot Notify Committed (indicating that it committed) state. If the transaction is aborted on the parent computer, manually force the transaction to abort on that computer's immediate child. If the transaction is committed on the parent computer, manually force the transaction to commit on the child computer.
Once you have either manually committed or aborted the transaction on the child computer, manually force the immediate parent to forget the transaction.

Cannot Notify Committed

The Cannot Notify Committed state indicates that the transaction has committed, but some subordinate MS DTCs have not been notified. You can manually resolve the transaction as follows. Right-click on the transaction that is in the Cannot Notify Committed state. This displays the parent and subordinate MS DTCs for the transaction. Having located the subordinate MS DTCs, force the transaction to commit on each one. Once you have manually committed the transaction on all subordinate MS DTCs, return to the MS DTC that shows the transaction in the Cannot Notify Committed state, and force that MS DTC to forget the transaction.

Caution: Do not manually forget a transaction until all subordinate MS DTCs have been notified of the transaction outcome.

Cannot Notify Aborted

The Cannot Notify Aborted state indicates that the transaction has aborted, but some subordinate MS DTCs have not been notified. This state is identical to the Aborting state. You can manually resolve the transaction as follows. Right-click the transaction that is in the Cannot Notify Aborted state. This displays the parent MS DTC and subordinate MS DTCs for the transaction. Having located the subordinate MS DTCs, force the transaction to abort on each one. Once you have manually aborted the transaction on all subordinate MS DTCs, return to the MS DTC that shows the transaction in the Cannot Notify Aborted state, and force that MS DTC to forget the transaction.