During crash recovery, SAP ASE may also encounter prepared transactions that were coordinated using SAP ASE transaction coordination services or the X/Open XA protocol.
Upon encountering these transactions, the local server must wait for the coordinating SAP ASE or the external transaction coordinator to initiate contact and indicate whether the prepared transaction should commit or roll back.
To speed the recovery process, SAP ASE 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 SAP ASE, 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 SAP ASE 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 SAP ASE or external transaction manager cannot complete the transaction, the system administrator can heuristically complete the transaction to free its locks and transaction resources.