During crash recovery, Adaptive Server may also encounter prepared transactions that were coordinated using Adaptive Server transaction coordination services or the X/Open XA protocol. Upon encountering these transactions, the local server must wait for the coordinating Adaptive Server or the external transaction coordinator to initiate contact and indicate whether the prepared transaction should commit or roll back.
To speed the recovery process, Adaptive Server restores each of these transactions to their condition prior to the failure. The transaction manager creates a new transaction with the original transaction ID, and the lock manager applies locks to protect data that the original transaction was modifying. The restored transaction remains in a prepared state but is detached, having no thread associated with it.
Once the transaction’s coordinator contacts Adaptive Server, the transaction manager can commit or roll back the transaction.
Using this recovery mechanism, the server can bring a database online even when the coordinating Adaptive Server or external transaction manager has not yet attempted to resolve the prepared transaction. Other clients and transactions can resume work on the local data, since the prepared transaction holds the locks it did prior to recovery. The prepared transaction itself is ready to commit or roll back once contacted by its coordinator.
When the controlling Adaptive Server or external transaction manager cannot complete the transaction, the System Administrator can heuristically complete the transaction to free its locks and transaction resources. See “Heuristically completing transactions” for more information.
