Recovering Failed Transactions


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Using the BEA Tuxedo Domains Component \| Local Topics \| Previous Topic \| Next Topic \| Contents

When a domain gateway group is booted, the gateway server performs an automatic warm-start of the DMTLOG. The warm-start includes scanning the log to see if any transactions were not completed. If incomplete transactions are found, action is taken to complete them.

In OSI TP, any blobs stored in the DMTLOG with a transaction record are passed to the network access module, which uses the blobs to reconstruct its internal state and to recover any failed connections

In the case of heuristic decisions, if a domain gateway group is a subordinate of a local TMS and a heuristic decision has been indicated, the TMS generates a TMS_STATUS message to learn the final decision:

If a gateway fails, then it cleans up after itself when it is restarted (this is called a hot-start). The gateway rolls back all undecided transactions in which it was involved.
If a communication line failure occurs and the first phase of the commit has not been completed, the gateway rolls back the transactions associated with that connection.
If OSI TP Domains is being used and a transaction fails in the second phase of the commit, recovery is managed by XAP-TP.