| GlassFish Server Open Source Edition 3.1 - Delegated Transaction Recovery 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: Marina Vatkina: mvatkina@java.net 1.3. Date of This Document: 05/13/10 2. Project Summary 2.1. Project Description: Support delegated transaction recovery in GlassFish Server Open Source Edition 3.1 with transaction logs stored in a file system. No new functionality will be added as compared to GlassFish 2.1.1. 2.2. Risks and Assumptions: The new implementation will replace GMS fencing used in GlassFish 2.1.1 with locks based on the shared file system and managed by transaction service itself. 3. Problem Summary 3.1. Problem Area: Delegated transaction recovery is an important part of the clustering and failover support. GMS fencing as implemented in GlasFish 2.1.1, uses an unreliable protocol to save the state transitions of the recovery states in the shared cache. In addition, there occasional bugs had been reported by customers where turning delegated transaction recovery unintentionally in their loaded system on, caused instances intermittently hanging due to a race condition. 3.2. Justification: Feature parity with GlassFish 2.1.1 4. Technical Description: 4.1. Details: Delegated transaction recovery will be supported in two ways:
- Manual recovery using asadmin CLI
- Automated recovery as a result of the GMS notification.
Manual recovery implementation will be based on full support for the --transactionlogdir, --destination, and --target options to the asadmin recover-transactions CLI and will have exactly the same user visible behavior as in GlassFish 2.1.1. Automated recovery implementation will replace GMS fencing for locking and storing information about the instances involved in the recovery process with locks based on the file system, managed by transaction service itself. Similar to GlassFish 2.1.1 corresponding feature, the new implementation will allow support of scenarios when a delegated recovery was attempted but not completed in case an instance that started the delegated recovery crashed before completing the task. To do so, an empty file will be placed in a shared file system directory specified by TX-LOG-DIR (which is part of the shared file system setup). The name of the file will be constructed from the instance names, starting with the name of the instance that is performing the recovery. If such instance crashes, and a new instance is designated to do the recovery, the latter can easily identify the former and it's target, to perform an unfinished operation. The new code should also allow for extension to support database based transaction logging. 4.2. Bug/RFE Number(s): 11966 11967 12212 4.3. In Scope: Manual and automated delegated transaction recovery for transaction logs stored in a shared file system 4.4. Out of Scope: Delegated transaction recovery for logs not accessible from another instance or stored in a database. 4.5. Interfaces: 4.5.1 Public Interfaces No change from GlassFish 3.0
- Interface: All classes and interfaces in transaction/internal-api module
- Stability: Evolving
- Comments:
- com.sun.enterprise.transaction.api package contains interfaces to be used by modules accessing transaction service
- com.sun.enterprise.transaction.spi package contains interfaces to be implemented by modules interacting with transaction service (like connectors, or Web, or EJB)
- Interface: asadmin recover-transactions
- Comments: stability defined by GlassFish CLI.
4.5.2 Private Interfaces No change from GlassFish 3.0 4.5.3 Deprecated/Removed Interfaces: N/A 4.6. Doc Impact: While 3.1 will support only transaction logs stored in a shared file system, the 2.x documentation (incorrectly) listed storing them in a database as a valid option. The latter was not fully supported, and if we chose to keep any relevant description in the docs, we will need to clearly document all limitations. 4.7. Admin/Config Impact: Will add support for --target option for transaction service CLI recover-transactions. Corresponding behavior will be identical to GlassFish 2.1.1. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: Minimal. Only new log and exception messages will need to be localized. 4.10. Packaging, Delivery & Upgrade: 4.10.1. Packaging Will follow GlassFishv 3.1 Packaging 4.10.2. Delivery No setup changes are expected in comparison with GlassFish 2.1.1. 4.10.3. Upgrade and Migration: Do not expect any requirements. 4.11. Security Impact: N/A 4.12. Compatibility Impact No compatibility changes are expected. 4.13. Dependencies: No external dependencies. 4.13.1 Internal Dependencies
- admin cluster support
- admin module changes to support new asadmin parameter
- GMS ( for failure detection notifications )
4.13.2 External Dependencies N/A Indicate which milestones from the current schedule the project
will be:
- Integration of this feature will begin with when internal dependencies are resolved, with Milestone 3 the latest, and continue through Milestone 5.
- The features will be complete at Milestone 5.
- At production quality level by the HCF.
|
