Patent Application
20080270487
The Java Transaction API (JTA) is a Java API that allows distributed transactions to be done across multiple XA resources. JTA is a specification developed under the Java Community Process as JSR 907. JTA provides for demarcation of transaction boundaries; X/Open XA API allowing resources to participate in transactions.
In the X/Open XA architecture, a transaction manager or transaction processing monitor (TP monitor) can coordinate the transactions across multiple resources such as a database. Each resource has its own manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API used by relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between it and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, commit or rollback the transactions. The application also communicates with the individual resources using their own API to modify the resource.
Application servers can maintain these transactions for JTA or other transaction processing systems using Transaction Recovery Services (TRS). The transaction recovery service can maintain a Transaction Log (TLOG) to allow the application server to recover from a crash that affects or flight transactions.
The application server can be part of a cluster. In past systems, when the application server goes down, the TRS can be manually migrated to another application server instance or the system can wait until the crashed application server instance reboots.
Embodiments of the present invention can include detecting the failure of a first application server instance 102 of a cluster 104. A transaction recovery service 106 can be automatically migrated from the first application server instance 102 to a second application server instance 108 without requiring rebooting the first application server instance 102.
The transaction recovery service 106 can fail back to the first application server instance after the transaction recovery is finished or when the first application server instance reboots.
A Singleton Monitor 112 can detect the failure of the first application server instance 102 and be charge of mitigating the transaction recovery service 106. The transaction recovery service can be Java Transaction API (JTA) service.
The transaction recovery service 106 can be in charge of transactions for application server 102. Shared storage 120 can store information related to the transactions. In one example, a Transaction Log (TLOG) 122 for application server 102 includes the status of in-flight transactions initiated by application server 102. In one embodiment, the TLOG 122 indicates the completed transactions. The transaction recovery service 106 can be used to roll back any uncompleted transactions.
In a transaction, there are typically multiple transaction members, such as transaction members 124 and 126, who each must complete or fail the transaction as a unit. There is typically two phases to a transaction: a prepare phase where transaction members indicate whether they can do their part of the transaction and a commit/rollback phase where the transaction is either committed or rolled back.
The application server code 200 can include code 202 to detect the failure of transaction recovery services; and include code 204 to migrate a transaction recovery service from a failed first application server instance to a second application instance without requiring rebooting the first application server instance.
In one embodiment, when primary server crashes, Singleton Monitor 112 can detect this and automatically migrate the transaction recovery service to backup server. The administrator can also do manually migration. The automatic migration policy can be configured.
An administrator can manually migrate primary server's TRS to another backup server. When recovery is done on back up server, the backup server can initiate failback. When primary server reboots before recovery is done on the backup server, the primary server can initiate failback. An administrator can manually migrate the transaction recovery service back to primary server.
Servers can be shutdown immediately if the health state, such as a JTA health state, becomes FAILED when auto TRA migration policy is running.
The Singleton Monitor 304 can then choose a backup server 306. If possible, the primary server 302 can execute a post-script to dismount the TLOG disk at shared storage 308. Shared storage 308 can be used to store the TLOG.
The backup server 306 can also run a pre-script to mount the TLOG disk. The pre-script and post-script are defined code that run before and after the transfer of the transaction recovery service. The backup server 306 can then start to recover the transaction on behalf of a primary server.
The primary server 302 can request a failback. The Singleton Monitor 304 can then tell the backup server 306 to deactivate control of the transaction recovery service for the primary server. The backup server 306 can then run a post-script to dismount the TLOG disk.
The Singleton Monitor 304 can then initiate the transaction recovery service at primary server 302. The primary server 302 can also execute a prescript to mount the TLOG disk.
Past JTA TRS services only support manual migration. When a server within a cluster fails, the administrator can migrate the JTA TRS service to the backup server manually. The new JTA feature “Automatic JTA Migration” can support automatic JTA TRS service migration.
In one embodiment, users can enable JTA automatic migration on one server within cluster. If this server (primary server) fails, JTA TRS service of primary server can be automatically migrated to another server (backup server) in the same cluster.
Both manual JTA migration and automatic JTA migration can potentially be used independently at the same time. For example, if server1 crashes, TRS of server1 gets auto-migrated to server2 (server2 can be selected based on the order of candidate servers list); it is possible for the administrator to manually migrate TRS of server1 from server2 to yet another server.
Each application server can have one TRS running on it, to recover any pending transactions on behalf of it.
JTA primary TLOG can be stored in file system through the default persistent store mechanism.
A user can have the ability to specify whether automatic JTA migration is enabled on a server. In one embodiment, if this configuration is not turned on, then only manual JTA migration is allowed. If this configuration is turned on, then the new migration feature will take place.
This new feature does not require the default store be migratable. It need not change configuration and behavior of current default store. Default store can target to local server.
In one embodiment, the restrictions on automatic/manual JTA migration are:
In one embodiment, the user can configure automatic JTA Migration using console. A user can specify whether automatic JTA migration is enabled for one server through console.
The user can specify a checkbox in console. If the checkbox is checked, then it equals to MigrationPolicy=‘failure-recovery’, and automatic JTA migration can be enabled; If the checkbox is not checked (this is the default configuration), then it equals to MigrationPolicy=‘none’, and automatic JTA migration will be disabled. User can also optionally specify following configurations both for automatic and manual JTA migration:
Pre Script; Post Script; isPostScriptFailureFatal; and isNonLocalPostAllowed. MigrationPolicy can be specified as only one of two possible values: none: automatic JTA migration will be disabled; or failure-recovery: automatic JTA migration will be enabled. There can be validation to enforce this.
The execution of user-defined scripts on the server machine can be a security concern and steps done to mitigate this.
Because JTAMigratableTargetMBean extends MigratableTargetMBean, this feature can be accessed through methods in class MigratableTargetMBean. The methods can include:
Beside above methods, several methods are added to JTAMigratableTargetMBean:
When configuring JTA, the permitted value for policy can be: ‘none’, ‘failure-recovery’. The ‘none’ means automatic JTA migration is disabled, and this is the default value. The ‘failure-recovery’ means automatic JTA migration is enabled.
User can configure automatic JTA migration by modifying an application server configuration file “config.xml” directly.
Following is a sample configuration which enables automatic JTA migration and specifies two scripts:
If <migration-policy> element is not appeared, then it can mean automatic JTA migration is disabled and only manual JTA migration is allowed.
When the primary server fails, the migratable service framework can automatically migrate the JTA TRS (primary server) service to a backup server. The framework can select a backup server from all candidate servers according to configuration. If a backup server fails before completing the transaction recovery actions, similar automatic migration sequences can also happen to migrate the TRS to another backup server. This can be handled by migration framework and is consistent with other migratable services.
After migration success, if backup server shutdown normally, then when backup server reboot again, the TRS (primary server) can again be activated on backup server.
In one embodiment, there are two cases for fail-back:
For both manual and automatic migration, any post-deactivation and pre-activation scripts can be executed automatically. This can be supported by migration framework.
Embodiments of the present invention can include computer-based methods and systems which may be implemented using conventional general purpose or a specialized digital computer(s) or microprocessor(s), programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by programmers based on the teachings of the present disclosure.
Embodiments of the present invention can include a computer readable medium, such as computer readable storage medium. The computer readable storage medium can have stored instructions which can be used to program a computer to perform any of the features present herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, flash memory or any media or device suitable for storing instructions and/or data. The present invention can include software for controlling both the hardware of a computer, such as general purpose/specialized computer(s) or microprocessor(s), and for enabling them to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.
Embodiments of the present invention can include providing code for implementing processes of the present invention. The providing can include providing code to a user in any manner. For example, the providing can include transmitting digital signals containing the code to a user; providing the code on a physical media to a user; or any other method of making the code available.
Embodiments of the present invention can include a computer-implemented method for transmitting the code which can be executed at a computer to perform any of the processes of embodiments of the present invention. The transmitting can include transfer through any portion of a network, such as the Internet; through wires, the atmosphere or space; or any other type of transmission. The transmitting can include initiating a transmission of code; or causing the code to pass into any region or country from another region or country. A transmission to a user can include any transmission received by the user in any region or country, regardless of the location from which the transmission is sent.
Embodiments of the present invention can include a signal containing code which can be executed at a computer to perform any of the processes of embodiments of the present invention. The signal can be transmitted through a network, such as the Internet; through wires, the atmosphere or space; or any other type of transmission. The entire signal need not be in transit at the same time. The signal can extend in time over the period of its transfer. The signal is not to be considered as a snapshot of what is currently in transit.
The forgoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, steps preformed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular used contemplated. It is intended that the scope of the invention be defined by the claims and their equivalents.
This application claims priority to U.S. Provisional Application No. 60/914,636 entitled “AUTOMATIC JTA MIGRATION”, filed Mar. 27, 2007 [Atty. Docket No. BEAS-02219US0], by Wilson Tian et al., which is herein incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60914636 | Apr 2007 | US |
