Product SiteDocumentation Site

Chapter 2. Architecture of the Recovery Manager

2.1. Crash Recovery Overview
2.2. Recovery Manager
2.2.1. Managing recovery directly
2.2.2. Separate Recovery Manager
2.2.3. In process Recovery Manager
2.2.4. Recovering For Multiple Transaction Coordinators
2.3. Recovery Modules
2.3.1. JBossTS Recovery Module Classes
2.4. A Recovery Module for XA Resources
2.4.1. Assumed complete
2.5. Recovering XAConnections
2.6. Alternative to XAResourceRecovery
2.7. Shipped XAResourceRecovery implementations
2.8. TransactionStatusConnectionManager
2.9. Expired Scanner Thread
2.10. Application Process
2.11. TransactionStatusManager
2.12. Object Store
2.13. Socket free operation

2.1. Crash Recovery Overview

The main architectural components within Crash Recovery are illustrated in the diagram below:
Recovery Manager Architecture
Figure 2.1. Recovery Manager Architecture

The Recovery Manager is a daemon process1 responsible for performing crash recovery. Only one Recovery Manager runs per node. The Object Store provides persistent data storage for transactions to log data. During normal transaction processing each transaction will log persistent data needed for the commit phase to the Object Store. On successfully committing a transaction this data is removed, however if the transaction fails then this data remains within the Object Store.
The Recovery Manager functions by:
  • Periodically scanning the Object Store for transactions that may have failed. Failed transactions are indicated by the presence of log data after a period of time that the transaction would have normally been expected to finish.
  • Checking with the application process which originated the transaction whether the transaction is still in progress or not.
  • Recovering the transaction by re-activating the transaction and then replaying phase two of the commit protocol.
The following sections describe the architectural components in more detail.