WO2003073281A1

WO2003073281A1 - Highly available transaction recovery for transaction processing systems

Info

Publication number: WO2003073281A1
Application number: PCT/US2003/004071
Authority: WO
Inventors: Priscilla Fung; Alexander J. Somogyi
Original assignee: Bea Systems, Inc
Priority date: 2002-02-22
Filing date: 2003-02-12
Publication date: 2003-09-04
Also published as: AU2003216238A1

Abstract

A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service (100). In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server.

Description

HIGHLY AVAILABLE TRANSACTION RECOVERY FOR TRANSACTION PROCESSING SYSTEMS

Claim to Priority [0001] The present application claims the benefit of priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application entitled "HIGHLY AVAILABLE TRANSACTION RECOVERY FOR TRANSACTION PROCESSING SYSTEMS", Patent Application No. 60/359,226, filed on February 22, 2002, which application is incorporated herein by reference.

Copyright Notice [0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Cross Reference to Related Applications [0003] The present application is related to the following United States Patents and Patent Applications, which patents/applications are assigned to the owner of the present invention, and which patents/applications are incorporated by reference herein in their entirety:

[0004] United States Provisional Patent Application No. 60/358,418, entitled "System and Method for Migratable Services [Manual]", filed on February 21, 2002, currently pending;

[0005] United States Provisional Patent Application No. 60/358,662, entitled

"System and Method for Automated Service Migration", filed on February 21,

2002.

[0006] United States Patent Application No. 10/341,207, entitled "METHOD FOR HIGHLY AVAILABLE TRANSACTION RECOVERY FOR

TRANSACTION PROCESSING SYSTEMS ", filed on January 13, 2003, currently pending, which claims priority to provisional United States Patent Application entitled "HIGHLY AVAILABLE TRANSACTION RECOVERY FOR TRANSACTION PROCESSING SYSTEMS", Patent Application No. 60/359,226, filed on February 22, 2002; and

[0007] United States Patent Application No. 10/341,041, entitled "SYSTEM FOR HIGHLY AVAILABLE TRANSACTION RECOVERY FOR TRANSACTION PROCESSING SYSTEMS ", filed on January 13, 2003, currently pending, which claims priority to provisional United States Patent Application entitled "HIGHLY AVAILABLE TRANSACTION RECOVERY FOR TRANSACTION PROCESSING SYSTEMS", Patent Application No. 60/359,226, filed on February 22, 2002.

Background of the Invention [0008] Distributed networks are well known to programmers and computer system architects. A distributed network may include multiple nodes, computers, or servers. As used herein, a server is defined as a software process. A node or cluster is a group of servers that may exist on a single hardware P T/US03/04071

machine or share a physical resource such as a memory disk. Each server in a network usually has applications or objects that perform different functions. An application on a particular server may be initiated by another server or by the server it resides on. Distributed networks are advantageous in that several applications required to accomplish a task or a process may be distributed among several servers. The distributed applications may then be called upon when needed. Processes invoked simultaneously may be run on different servers instead of weighing down a single server and processor. This advantageously distributes processing power and contributes to a more efficient network.

[0009] Distributed transactions can span multiple servers, and servers often host resource managers (e.g. database connection pools or JMS queues) which participate in distributed transactions. As a result of distributed transaction participation, locks or other internal resources can be held up in the resource managers (e.g. databases locks are acquired for database records that are updated in a distributed transaction) on behalf of the distributed transaction until the distributed transaction is completed. For each distributed transaction, a particular server acts as the coordinator, which drives the participating transactional resources to commit atomically, and thus the transaction to completion, via the Two Phase Commit (2PC) protocol, h the first phase of the 2PC protocol, the coordinator logs a record of the transaction and its participants persistently in its TLOG files after all participants are prepared successfully. Once prepared, all participants hold on to the acquired locks or other internal resources for the transaction until it is told to commit or rollback by the coordinator. In the second phase of the 2PC protocol, the coordinator commits all the participants, which then make the updates durable and release the locks and other internal resources. After all participants are successfully committed, the coordinator then releases the log record from its TLOG. Thus, if a coordinator fails, all the in-flight transactions that are logged in its TLOG files cannot be driven to completion, and thus all participants cannot release their locks or other internal resources, until the coordinator is restarted. . Thus, with systems of the prior art, transaction recovery cannot take place before a failed server restarts. This limits the availability of transaction recovery of the failed server and thus the availability of other XA resources (e.g. JMS backends). [0010] In addition to unexpected server failure, a server may be brought down intentionally. Application servers are often configured to run on specific machines to service client requests. These machines are brought down for periodic maintenance, machine servicing, and other reasons. As a result, the servers located on the downed machine are not able to service client requests to that machine or perform recovery of in-doubt transactions until the servers are restarted. [0011] One approach the prior art has taken to address this problem is to migrate servers and their TLOG files to a back-up or alternate machine. This allows unfinished transactions in a TLOG to be processed thus improving the availability of the failed server and preserving the operation and efficiency of a network. One such server migration system for use in a distributed network is included in the BEA TUXEDO application. TUXEDO supports migration of multiple servers residing on a machine. The servers must either consist of a group of servers or all the servers that reside on a machine. A group of servers within the TUXEDO application is defined as a collection of servers or services on a machine, often associated with a resource manager. [0012] An administrator manually migrates servers using the TUXEDO application. The administrator specifies a primary machine and an secondary or back-up machine for each group of servers. Once a server group has failed or been deactivated by a user, a user may manually migrate the servers from the primary machine to the secondary machine. The primary then becomes the acting secondary machine, and the secondary becomes the acting primary machine. When the group of servers is to be moved back to the original primary machine, the user shuts-down the back-up machine and then migrates the server group back to the original primary machine. [0013] Though a TLOG cannot be migrated by itself in Tuxedo, an administrator may manually migrate a TLOG file to a back-up server as a secondary step to of migrating a server. The TLOG migration is a manual process performed with tmadmin commands. To migrate a TLOG in TUXEDO, a "tmadmin" session is started and all servers that write to the TLOG are manually shut-down by a user. Next, the user dumps the TLOG contents into a text file, copies the name of the TLOG file to the back-up machine, and reads the text file into the existing TLOG for the specified back-up machine. The user then forces a warm start of the TLOG. Though a user may manually migrate a TLOG in this manner, TUXEDO does not support having multiple TLOGs per server.

[0014] There are several disadvantages to the prior art such as the TUXEDO application. Tuxedo does not support the migration of anything less than a group of servers. Thus, if a single server has crashed in a system or requires maintenance, multiple servers must be shut-down in order to migrate the server. Tuxedo requires that all servers that write to a particular TLOG file must be shut-down while the TLOG file is migrated. Tuxedo also does not support multiple TLOGs residing on a single server. In Tuxedo, there is only one TLOG for a group of servers. Once servers of a machine or group have migrated, and the corresponding TLOG is migrated thereafter, the secondary machine hosts only the migrated TLOG. Additionally, all migration steps in Tuxedo are done manually, including a complete shut-down of the secondary server when failing back to the original primary or master server. What is needed is a migration system that addresses the deficiencies of existing migration systems such as the one in Tuxedo.

Summary of the Invention [0015] A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service as a migratable service, one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. Highly available transaction recovery of a server within a cluster is achieved by migrating the TRS to another available server in the same cluster. This allows the backup server to read the transaction log and perform recovery on the behalf of the failed server. Each server in a cluster has a corresponding TRS, which maintains ownership of the servers' s TLOG.

When a primary server fails, the failed servers' s TRS migrates to an available secondary server that resides in the same cluster as the failed server. The primary server and secondary server share access to the same memory disk. While residing on the secondary server, the migrated TRS obtains access to the TLOG of the failed primary server, reads the transaction log, and performs transaction recovery on behalf of the failed server. Multiple TRS instances may reside on any server, all of which performing transaction recovery on a single server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed primary server migrates back to the primary server in a fail back operation once the failed primary server is restarted. Fallback operation may occur whether recovery is completed or not. No servers need to be shutdown during TRS failover migration to a secondary server or during TRS fallback migration to the primary server. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers. Brief Description of the Drawings [0016] FIGURE la is a block diagram of a transaction recovery service ' migration system in accordance with one embodiment of the present invention.

[0017] FIGURE lb is a block diagram of a transaction recovery service migration system after failover in accordance with one embodiment of the present invention.

[0018] FIGURE 2 is a diagram of a flow chart showing manual migration failover operation in accordance with one embodiment of the present invention.

[0019] FIGURE 3 is a diagram of a GUI for managing migration services in accordance with one embodiment of the present invention.

[0020] FIGURE 4 is a diagram of a flow chart showing manual migration fallback operation after recovery is complete in accordance with one embodiment of the present invention.

[0021] FIGURE 5 is a diagram of a flow chart showing manual migration fallback operation before recovery is complete in accordance with one embodiment of the present invention.

[0022] FIGURE 6 is a diagram of a flow chart showing automatic migration failover operation in accordance with one embodiment of the present invention.

[0023] FIGURE 7 is a diagram of a flow chart showing automatic migration fallback operation after recovery is complete in accordance with one embodiment of the present invention. [0024] FIGURE 8 is a diagram of a flow chart showing automatic migration fallback operation before recovery is done in accordance with one embodiment of the present invention.

Detailed Description

[0025] A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. Highly available transaction recovery of a server within a cluster is achieved by migrating the TRS to another available server in the same cluster. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. A server may host multiple TRS instances at any time as well as coordinate their corresponding TLOG transactions. In one embodiment of the present invention, though a server may host multiple TRS instances and TLOGS, each TRS and TLOG corresponds to only one server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Fallback operation may occur whether recovery is completed or not. No servers need to be shutdown during TRS failover migration to a secondary server or during TRS fallback migration to the primary server. This expedites recovery of the failed server and while preserving the efficiency of the network and other servers.

[0026] A transaction recovery service migration system 100 in accordance with one embodiment of the present invention is shown in FIG. la. System 100 includes servers 110, 120 and 140. Each server has a corresponding TRS instance 112, 122, and 142, respectively. Servers 110 and 120 share a common disk 130 while server 140 utilizes a separate disk 150. Each server has a corresponding transaction log (TLOG) that resides on a disk. Server 110 has TLOG 114 on disk 130, server 120 has TLOG 124 on disk 130, and server 140 has TLOG 144 on disk 150. All servers may reside on a single cluster 160. Servers within a cluster may reside on the same or different machines (not shown).

[0027] In one embodiment of the present invention, each server is associated with only one TLOG. Each TRS has exclusive ownership of the TLOG for it's particular server. Thus, TRS 122 has exclusive ownership of the TLOG for server 120, TLOG 130. When a particular server fails, the TRS for the failed server may be migrated to an alternate server. The migrated TRS may then perform recovery on the failed server's TLOG while residing on the alternate server, hi one embodiment of the present invention, a TRS may only be migrated to a server that has access to the same disk space as the failed server. In particular, the shared disk space must contain TLOG files for the failed server. In another embodiment, an administrator may transfer the TLOG file for the failed server to the disk that the alternate server can access. The shared disk space may be a dual-ported SCSI, a storage area network (SAN), or some other reliable shared disk architecture.

[0028] For example, if server 110 fails, the TRS 112 can migrate to server 120 as shown in FIG. lb. Once at server 120, TRS1 112 performs recovery on TLOG 114 corresponding to server 110. In this case, server 110 is the primary server and server 120 is the back-up, secondary, or alternate server. A migration of a TRS from a primary server to a secondary server is called failover. In one embodiment of the present invention, a TRS may undergo failover migration to a server that shares access to the memory containing the TLOG of the failed server, hi FIG. lb, TRS 112 could not perform recovery on server 110 if migrated to server 140 because server 140 and server 110 do not share access to memory 130. If TRS 112 migrates to server 140, recovery by TRS 112 would require that server 140 obtain access to memory disk 130 or experience another migration to a server with access to disk 130. [0029] Each TRS is also associated with a migratable target as an alternate server. In one embodiment, administrators can configure a jTAMigratabieTarget element for a clustered server. One example of a TAMigratableTarget configuration is as follows:

^[0⁰30^] <Server Name="serverl" Cluster="mycluster" ListenAddress="campton-1" ListenPort=" 7001" > <JTAMigratableTarget Name=" serverl" ConstraintedCandidateServers="serverl, server2 " /></Server>

[0031] The runtime information is available from a JTA runtime MBean: JTARecoveryRuntimeMBean, which can be obtained from a JTARuntimeMBean MBean. In one embodiment, at least two methods of the JTARuntimeMBean MBean may provide access to the JTARecoveryRuntimeMBean. One method is:

[0032] JTARecoveryRuntimeMBean[] getRecoveryRuntimeMBeansQ.

[0033] This method returns an array of JTARecoveryRuntimeMBean MBeans that corresponds to the TRS instances that are deployed on the current server. Another method is:

[0034] JTARecoveryRuntimeMBean getRecoveryRuntimeMBean(String serverName).

[0035] This method returns the JTARecoveryRuntimeMBean MBean that is associated with the specified server. If the corresponding JTARecoveryRuntimeMBean MBean is not deployed on this server, null is returned. The JTARecoveryRuntimeMBean MBean has several methods as well. One method is:

[0036] boolean isActiveO

[0037] This method returns whether the Transaction Recovery Service is currently activated on the server. Another method is:

[0038] int getInitialRecoveredTransactionTotalCount().

[0039] This method returns the total number of transactions that are read from the transaction log by the TRS. The administrator may use this information to increase the value of the MaxTransactions attribute of the JTAMBean MBean as appropriate. Another method is:

[0040] int getRecoveredTransactionCompletionPercentQ.

[0041] This method returns the percentage of the recovered transactions that are completed by the Transaction Recovery Service. In one embodiment, the name of the JTARecoveryRuntimeMBean MBean is the name of the original server of the Transaction Recovery Service.

[0042] Though failover and fallback migration usually involve moving a single TRS instance at any time, a server may facilitate multiple TRS instances residing on the server and coordinate multiple transactions for TLOGs corresponding to the multiple TRS instances. In this case, the server performs recovery for multiple TRS instances in parallel. Server 120 in FIG. lb facilitates recovery for failed server 110 as well as its own recovery and normal processing. In one embodiment, only the primary server may service new transactions. In this embodiment, a back-up server can not service new transactions for a failed primary server. To regain its TRS and service new transactions, the failed primary server must restart and the TRS must migrate back to the primary server. Migration of a TRS from a secondary server back to a primary server is called fallback. Fallback operation may vary according to whether recovery for the failed server is completed or not before fallback occurs. After fallback, TRS 112 would again reside m server 110 as shown in FIG. la. [0043] In one embodiment of the present invention, manual migration failover is the only migration scenario that requires interaction by a user. An administrator may manually migrate the TRS of a failed server to another available server in the same cluster. The operation of a manual migration failover system in accordance with one embodiment of the present invention is shown in block diagram 200 of FIG. 2. Manual migration failover operation begins at start step 205. A first server instance (SI) fails in step 210. This may occur by an act of an administrator or by server malfunction. In step 220, a user issues a migrate command to trigger the migration of the transaction recovery service for the first server instance (TRS1) from SI to a second server instance (S2). This is usually done after the user has discovered a failed server or has shut-down a server. In one embodiment, a user my trigger the migration of TRS1 from SI to S2 using a console implemented as a GUI system. The GUI console may be implemented so as to graphically display different clusters and servers. The user may choose a server having the corresponding TRS to migrate and the back-up server to receive the TRS. hi one embodiment, the migration would be performed using a Java Transaction API (JTA). A JTA Recovery tab is provided for each server that allows administrators to specify various attributes of a Migratable Target and perform manual migration of the Transaction Recovery Service associated with the server. The appearance as 4071

15

viewed on a computer screen of a GUI allowing a user to issue a migrate command in accordance with one embodiment of the present invention is shown in FIG. 3. In another embodiment of the present invention, a user or system administrator may trigger a manual migration of a TRS using a command line. A command line administration tool, implemented as a Java program, may allow a user to specify the TRS to be migrated and what server to migrate the TRS to. The command line tool may also require a user to enter a username and password in order to perform the migration. The general format of such a command line command in accordance with one embodiment of the present invention is shown below.

[0044] Java weblogic. Admin [-url <url>] [-username <username>] [-password <password>] MIGRATE -jta -migratabletarget <server name> -destination destination servername> [0045] [-sourcedown] [-destinationdown]

In another embodiment of the present invention, manual migration may be triggered by a user pro grammatically using a JMX MBean. In particular, a JMX MigratableTarget MBean of the TRS may be used to trigger the migration of a TRS from one server to another. An example of the code comprising a MigratableTarget MBean in accordance with one embodiment of the present invention is below.

import weblogic .management .Admin; import weblogic .management . configuration.MigratableTargetMBe an; import weblogic .management . configuration. ServerMBean; import weblogic .management . runtime .MigratableServiceCoordina torRuntimeMBean; // Obtain the

MigratableServiceCoordinatorRuntimeMBean MigratableServiceCoordinatorRuntimeMBean msc = Admin . getAdminServer ( ) .getMigratableServiceCoordinato rRuntime () ;

// Obtain the MigratableTargetMBean of the server whose Transaction Recovery Service needs to be migrated

ServerMBean serverl = (ServerMBean)

Admin. getMBeanHome () . getConfigurationMBean ( "serverl" ,

"MigratableTargetConfig" ) ; >

MigratableTargetMBean mt = serverl .getJTAMigratableTarget () ;

// Obtain the configuration ServerMBean of the server to which the

Transaction Recovery Service will be migrated ServerMBean server2 = (ServerMBean)

Admin . getMBeanHome ( ) . getConfigurationMBean ( " server2 " , "MigratableTargetConfig") ;

// Perform the migration of Transaction Recovery Service of "serverl" to "server2" msc .migrateJT (mt, server2 , false /*source up*/, false /*destination up*/) ;

[0046] Though specific code is listed above, an MBean can be configured and implemented in various ways to achieve the result of triggering the migration of a TRS from one server to another. These variations of code are all considered within the scope of the present invention. The present invention is not intended to be limited to the JMX MigratableTarget MBean code example listed above. [0047] Next, the migratable framework detects that the SI is down in step 230. In one embodiment, the user issued command in step 220 informs the migratable framework that the server is down. When the migratable framework detects the server is down in step 220, the migratable framework moves the TRS to a back-up server. The back-up server may be specified by a user or be pre-determined by the migratable framework system. After step 230, the migratable framework then activates TRSl on S2 in step 240. i one embodiment, all migratable services including instance TRSl must implement a particular interface. The interface must be registered with the migratable framework and includes migration activate and deactivate methods, i this embodiment, migration is activated when the migratable framework calls the migration activate method of TRSl currently residing on S2. Then, TRSl reads and processes the TLOG for S 1 in step 250. TRS 1 reads S 1 's TLOG files, instantiates the transactions of the TLOG files, puts them into the transaction map of S2, and schedules resource recovery for SI . As a result, S2 services will read and coordinate the transactions from Si's TLOG. The S2 server becomes the coordinator of previously in doubt transactions and talks to different coordinators and resource managers to resolve transactions. Next, TRSl performs recovery on behalf of SI in step 260 while still residing on S2. TRSl performs recovery on behalf of SI asynchronously. Meanwhile, the backup server's own transaction manager functions to accept new transactions and perfonn its own transaction recovery as usual. Thus, there may be more than one instance of TRS activated on a back-up server at any time, the multiple TRS instances originating from different servers. The recovery may include driving prepared transactions to completion and performing resource recovery. Manual migration failover is then complete and operation ends at step 265. Similar manual migration can be performed to migrate the TRS to another available backup server if a backup server fails before completing the transaction recovery actions for the original server.

[0048] In one embodiment, failback occurs when a failed primary server restarts and is ready to receive its TRS instance back from a back-up server. The operation of a manual migration fallback perforated after recovery is completed in accordance with one embodiment of the present invention is shown in diagram 400 of FIG. 4. System operation begins with start step 405. In step 410, an alternate or back-up server S2 completes recovery for a primary server SI. In one embodiment, recovery completion occurs when TRS 1 of S 1 finishes recovery for SI while residing on S2. Once TRSl completes recovery, TRSl relinquishes control of Si's TLOG files. Next, TRSl migration back to SI is initiated in step 420. In one embodiment, an administrator may manually initiate migration of the TRS back to the original server, hi another embodiment, migration is initiated when TRS 1 contacts the migratable framework and makes a request to migrate TRSl back to SI. In step 430, the migratable framework completes the migration of TRSl from S2 back to SI. In one embodiment, the migratable framework first deactivates TRSl on S2 by calling a deactivation method of TRSl. During the deactivation of TRSl, S2 performs cleanup and removes any remaining transactions of SI from its internal transaction map. After this deactivation of TRSl, the migratable framework moves TRSl to SI. Then, the migratable framework activates TRSl on SI using a call to an activation method of TRSl. Operation then ends in step 435. When SI later restarts, SI will regain ownership of the TLOG corresponding to S 1 and will not need to perform further recovery work.

[0049] Manual migration fallback may also be performed before recovery is complete. Operation of manual migration fallback performed before recovery is completed in accordance with one embodiment of the present invention is shown in diagram 500 of FIG. 5. Operation begins at start step 505. In step 510, SI is restarted. Up until just before SI restart, S2 is still performing recovery work for SI. During SI startup, SI notifies S2 that SI is now operational. In one embodiment, the notification is in the form of an administrative MBean event sent from SI to S2. Next, TRSl migration back to SI is initiated in step 520. In one embodiment, TRSl residing on S2 sends a request to the migratable framework to migrate TRSl back to SI. Then, TRSl migrates from S2 to SI in step 530. In one embodiment, an administrator may manually migrate TRS 1 back to S 1 from S2. This may be performed when the back-up server fails to implicitly migrate TRSl back to the original server SI. During this manual migration, the migratable service framework deactivates the TRSl on S2. The deactivation of TRSl suspends recovery for SI and allows S2 to perform cleanup and remove any remaining transactions of SI from its internal transaction map. In another embodiment, the migratable framework first deactivates TRS 1 on S2 by calling a deactivation method of TRS 1. The deactivation of TRSl on S2 suspends recovery processing for SI. Thus, S2 may checkpoint the TLOG for SI, purge transactions in its transaction map originating from Si's TLOG, and stop resource recovery performed for SI. During the deactivation of TRSl, S2 performs cleanup and removes any remaining transactions of SI from its internal transaction map. S2 then relinquishes control of Si's TLOG. After this deactivation of TRSl, the migratable framework moves TRSl to SI. Then, the migratable framework activates TRSl on SI. TRSl is activated by issuing a call to an activation method of TRSl. Operation then ends in step 545. Though falling under the category of manual migration, no administrator intervention is required for manual migration fallback before recovery is done. Once SI regains ownership of TRSl, it restarts and completes the remaining transaction recovery work. [0050] Automatic migration occurs without any administrative intervention required. Automatic failover and fallback migration occur without any input from a user. In one embodiment, migration occurs seamlessly and without notification to the user. Operation of automatic migration failover in accordance with one embodiment of the present invention is shown in diagram 600 of FIG. 6. Operation begins at start step 605. Server failure of SI occurs at step 610. Next, TRSl is migrated to S2 in step 620. In one embodiment, TRSl migration to S2 is triggered when the migratable framework detects the failure of SI. The migratable framework then migrates TRSl from SI to S2. In one embodiment, a user may specify a preferred order of back-up servers. A preferred server list as indicated by a user may be stored in the migratable target MBean. The migratable framework will then attempt to migrate TRSl to the preferred back-up servers in the order specified by the user. Then, the migratable framework activates TRSl on S2 in step 630. h one embodiment, TRSl is activated when the migratable framework calls an migration activation method of TRSl. Next, Si's TLOG is read and processed in step 640. In one embodiment, during activation on S2, TRSl reads Si's TLOG files regarding SI transactions and configures S2 accordingly. In one embodiment, TRSl instantiates the SI TLOG files, places the files in S2's transaction map, and schedules resource recovery for SI. Thus, S2 is configured to be the coordinator of the transactions read from Si's TLOG. Next, TRSl performs recovery on behalf of SI in step 650. In one embodiment, recovery includes driving prepared transactions to completion and performing resource recovery. Automatic migration failover operation then ends in step 655. S2's own transaction manager and TRS2 function as usual during automatic migration failover. Similar manual migration can also be performed to migrate TRS 1 to another available backup server if a backup server S2 fails before completing the transaction recovery actions for the original server SI. [0051] Automatic migration fallback is similar to automatic migration failover in that no administrative intervention is required. Operation of automatic migration fallback after recovery is complete in accordance with one embodiment of the present invention is shown in diagram 700 of FIG. 7. Operation begins at start step 705. Next, SI recovery is completed in step 710. hi one embodiment of the present invention, recovery is completed when TRSl finishes recovery for SI while located on S2. The TRSl checkpoints Si's TLOG files and relinquishes control of Si's TLOG files. Then, TRSl migration back to SI is initiated in step 720. h one embodiment of the present invention, the migration is initiated when TRSl requests the migratable framework to migrate TRSl back to SI. Next, the migratable framework completes migration of the TRS to SI in step 730. The migratable framework first deactivates TRSl on S2 by calling a deactivation method of TRSl. TRSl deactivation results in S2 relinquishing control of Si's TLOG. During the deactivation of TRSl, S2 performs cleanup and removes any remaining transactions of SI from its internal transaction map. After this deactivation of TRS 1 , the migratable framework moves TRSl to SI. Then, the migratable framework activates TRSl on SI. TRSl is activated by issuing a call to an activation method of TRSl. Once migration is complete, operation ends in step 735. When SI is restarted, SI regains ownership of it's TLOG as a result of TRSl resides on SI. SI does not need to perform additional recovery work.

[0052] Automatic migration fallback may also occur before recovery of the failed server is complete. Operation of automatic migration fallback before recovery is complete in accordance with one embodiment of the present invention is shown in diagram 800 of FIG. 8. Operation begins with start step 805. Next, SI is restarted in step 810. At the time of SI restart, TRSl residing on S2 has not completed performing recovery on behalf of S 1. TRS 1 migration is then initiated in step 820. In one embodiment, the migratable framework initiates migration upon detecting that SI has performed startup. The migratable framework may detect the failure of the server itself or be notified of the server startup by an outside source. In one embodiment, SI informs S2 that SI has restarted. After migration has been initiated in step 820, the TRSl migrates to SI in step 830. In one embodiment, the migratable framework first deactivates TRSl on S2 by calling a deactivation method of TRSl. The deactivation of TRSl on S2 suspends recovery processing for SI by TRSl on S2. The deactivation includes checkpointing the TLOG for SI, purging transactions in its transaction map originating from Si's TLOG, and stopping resource recovery performed for SI. During the deactivation of TRSl, S2 performs cleanup and removes any remaining transactions of S 1 from its internal transaction map. S2 then relinquishes control of Si's TLOG files as TRS 1 migrates back to S 1. After this deactivation of TRS 1 , the migratable framework moves TRSl to SI. Then, the migratable framework activates TRSl on S 1. TRS 1 is activated by issuing a call to an activation method of TRS 1. Once migration is complete, operation ends in step 835. Once SI regains ownership of TRSl and restarts, SI performs the remaining recovery work. [0053] A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. Each server in a cluster has a corresponding TRS, which maintains ownership of the servers' s TLOG. When a primary server fails, the failed servers's TRS migrates to an available back-up server that resides in the same cluster as the failed server. The primary server and back-up server share access to the same memory disk. While residing on the back-up server, the migrated TRS obtains access to the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services network. Automatic migration requires the TRS be deployed on the migratable service framework. The TRS of the failed server migrates back to the primary server in a fail back operation once the failed primary server is restarted. Fallback operation may occur whether recovery is completed or not. This expedites recovery and improves the availability of the failed server thereby preserving the efficiency of the network and other servers. [0054] Examples of embodiments within the scope and spirit of the present invention are included in the Appendix to this patent disclosure. [0055] In addition to an embodiment consisting of specifically designed integrated circuits or other electronics, the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art.

[0056] Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

[0057] The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

[0058] Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor 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, and user applications. Ultimately, such computer readable media further includes software for implementing Node Managers.

[0059] Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to, separating planes of a source image, averaging at least one of foreground and background colors, replacing colors, and compensating for error introduced by color replacement in one plane by feeding error into a second plane, storage, communication of results, and reconstructing an image according to the processes of the present invention. [0060] Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims.

[0061] The foregoing 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. Obviously, many modifications and variations will be apparent to the practitioner skilled in the art. 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 use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence. 1

25

Appendix

1.1 Product Perspective

With systems of the prior art, transaction recovery cannot take place before a failed server restarts. This limits the availability of transaction recovery of the failed server and thus the availability of other XA resources (e.g. JMS 10 backends). In the present invention, we achieve highly available transaction recovery of a server within a cluster by migrating the Transaction Recovery Service to another available server in the same cluster. This allows the backup server to read the transaction log and perform recovery on the behalf of the failed server.

^ Transaction Recovery Service depends on the migratable service framework for manual and automatic migration support. JMS backends, which are XA resources, in turn depend on Transaction Recovery Service migration to recover their resources when they are migrated.

20

1.2 Product Functions

_ Manual migration (both fail-over and fail-back) of Transaction Recovery Service within cluster

25 _ Automatic migration (both fail-over and fail-back) of Transaction

Recovery Service within cluster

Note that this function is contingent upon automatic migration support from the migratable service framework.

™ Configuration, manual migration, and monitoring of Transaction Recovery 1.3 User Characteristics and Impact (usability - use cases/user interactions)

Administrators can configure, manually migrate and momtor Transaction Recovery Services via either the Administration Console or the JMX API.

Manual Migration

2.1 Functional Description

Administrators can manually migrate the Transaction Recovery Service of a failed server (i.e. the original server) to another available server in the same cluster. Before the original server restarts, the administrator may also need to manually migrate the Transaction Recovery Service back to the original server.

Manual migration is recommended if the server has failed and is not expected to be restarted soon. In the absence of migration, a server will perform its own transaction recovery when it is restarted after a failure.

2.2 Functional Requirements

2.2.1 Manual migration scenarios

There are two aspects of manual migration: fail-over and fail-back.

2.2.1.1 Fail-over

When a clustered server (Transaction Coordinator) fails, the Transaction Recovery Service associated with the failed server (i.e. the original server) can be manually migrated to another available server (the backup server) in the same cluster, via either the Administration Console or the JMX API. Please refer to [5] for description of the JMX API for manual migration. During the migration, the migratable service framework activates the Transaction Recovery Service on the backup server. During activation, the Transaction Recovery

Service reads the transaction log of the failed server and initializes the transaction recovery asynchronously. Meanwhile, the backup server's own transaction manager functions (accepting new transactions and performing its own transaction recovery) as usual. Note that there may be more than one instances of Transaction Recovery Service (that originates from different servers) activated on a backup server at the same time. Similar manual migration can also be performed to migrate the Transaction Recovery Service to another available backup server if a backup server fails before completing the transaction recovery actions for the original server.

2.2.1.2 Fail-back

Fail-back happens when migrating the Transaction Recovery Service from a backup server to the original failed server. Note that fail-back is implicit and does not require administrator intervention unless a migration error occurs, as described below.

2.2.1.2.1 Fail-back when recovery is done

When a backup server finishes transaction recovery before the original server restarts, it gives up ownership of the Transaction Recovery Service and migrates it back implicitly to the original server. No administrative action is needed in this case. Subsequently, when the original server restarts, it regains ownership of its Transaction Recovery Service. However, it does not need to do further recovery work.

2.2.1.2.2 Fail-back before recovery is done

When the resources to be recovered are not available, transaction recovery for the original server may not be finished when the original server is to be restarted. In this case, the backup server, on detecting that the original server is coming up, suspends the ongoing transaction recovery, performs some internal cleanup, and implicitly migrates the Transaction Recovery Service back to the original server. No administrative action is needed in this case. The original server, once it regains the ownership of its Transaction Recovery Service, restarts successfully and finishes the remaining transaction recovery work.

If the backup server fails to implicitly migrate back to the original server, the original server will fail to boot, hi this case, the administrator needs to manually migrate the Transaction Recovery Service from the backup server to the original server before rebooting the original server. During the manual migration, the migratable service framework deactivates the Transaction Recovery Service on the backup server. The deactivation suspends the transaction recovery, performs some internal cleanup and gives up ownership of the Transaction Recovery Service. Subsequently, when the original is restarted, it regains ownership of its Transaction Recovery Service and finishes the remaining transaction recovery work.

Automatic Migration

3.1 Functional Description

Under automatic migration, no administrator intervention is needed, and the migration of Transaction Recovery Service happens transparently under the control of migratable service framework.

3.2 Functional Requirements

3.2.1 Automatic migration scenarios

There are two aspects of automatic migration: fail-over and fail-back. 3.2.1.1 Fail-over

When the migratable service framework detects that a clustered server (Transaction Coordinator) has failed, it automatically migrates the Transaction Recovery Service associated with the failed server to the next available server (the backup server) in the preferred server list of the migratable target MBean. During the migration, the migratable service framework activates the Transaction Recovery Service on the backup server. During activation, the Transaction Recovery Service reads the transaction log of the failed server and initializes the transaction recovery asynchronously. Meanwhile, the backup server's own transaction manager (including its own transaction recovery) functions as usual.

Similar automatic migration sequences can also happen to migrate the Transaction Recovery Service to another backup server if a backup server fails before completing the transaction recovery actions.

3.2.1.2 Fail-back

This happens when migrating the Transaction Recovery Service from a backup server to the original failed server.

There are also two cases:

3.2.1.2.1 Fail-back without automatic migration

This is similar to fail-back when recovery is done for manual migration as described above in Section 3.2.1.2.1.

When a backup server finishes transaction recovery before the failed server restarts, it gives up ownership of the Transaction Recovery Service and migrates it back implicitly to the failed server. Subsequently, when the failed server restarts, it regains ownership of its Transaction Recovery Service. However, it does not need to do further recovery work. 3.2.1.2.2 Fail-back with automatic migration

This happens if the backup server has not finished transaction recovery when the original server restarts, hi this case, the backup server, on detecting that the original server is coming up, suspends the ongoing transaction recovery, performs some internal cleanup, and gives up the ownership of the Transaction Recovery Service of the original server. The migratable service framework will then transparently migrate the Transaction Recovery Service back to the original server. The original server, once it regains the ownership of the Transaction Recovery Service, restarts successfully and finishes the remaining transaction recovery work.

Administrative Requirements

Administrative means will be provided to configure, migrate and monitor Transaction Recovery Services.

4.1.1 Administration/Monitoring/Tuning requirements (e.g. console, system admin)

4.1.1.1 Configuring Transaction Recovery Service

Each server in a cluster is associated with a Transaction Recovery Service, and each Transaction Recovery Service is associated with a Migratable Target. If the Transaction Recovery Service is not configured for a particular server, no migration will be enabled. In this case, if the server fails, transaction recovery will only be performed after it restarts.

4.1.1.1.1 Configuring Transaction Recovery Service via the Console A new JTA Recovery tab for the server will be provided, from which administrators can specify various attributes of the Migratable Target and perform manual migration of the Transaction Recovery Service associated with the server.

4.1.1.1.2 Configuring Transaction Recovery Service via config.xml

Administrators can configure a JTAMigratableTarget element for a clustered server. Please refer to [5] for detailed information about configuring migratable targets in general.

The following is an example of the JTAMigratableTarget configuration: <Server Name="serverl" Cluster="mycluster" ListenAddress="campton-l" ListenPort="7001" >

<JTAMigratableTarget Name="serverl"

ConstraintedCandidateServers="serverl, server2" /></Server>

4.1.1.3 Monitoring JTA recovery service

Each server maintains runtime information of all Transaction Recovery Service instances that it hosts. The runtime information is available from a new JTA runtime MBean: JTARecoveryRuntimeMBean, which can be obtained from the existing JTARuntimeMBean MBean.

Two new methods are added to the existing JTARuntimeMBean MBean to provide access to the JTARecoveryRuntimeMBean:

_ JTARecoveryRuntimeMBean [] getRecoveryRuntimeMBeans ()

This method returns an array of JTARecoveryRuntimeMBean MBeans that corresponds to the Transaction Recovery Service instances that are deployed on the current server. JTARecoveryRuntimeMBean getRecoveryRuntimeMBean (String serverName)

This method returns the JTARecoveryRuntimeMBean MBean that is associated with the specified server. If the corresponding JTARecoveryRuntimeMBean MBean is not deployed on this server, null is returned.

The JTARecoveryRuntimeMBean MBean has the following methods:

_ boolean isActive O

This returns whether the Transaction Recovery Service is currently activated on the server.

_ int getlnitialRecoveredTransactionTotalCount ( )

This returns the total number of transactions that are read from the transaction log by the Transaction Recovery Service. The administrator may use this information to increase the value of the MaxTransactions attribute of the jTAMBean MBean as appropriate.

_ int getRecoveredTransactionCompletionPercent ()

This returns the percentage of the recovered transactions that are completed by the Transaction Recovery Service.

Note that the name of the JTARecoveryRuntimeMBean MBean is the name of the original server of the Transaction Recovery Service.

Claims

h the Claims:

1. A method for recovering transactions comprising: first performing failover migration of a transaction recovery service from a failed primary server to a back-up server, the primary server having a transaction log, the transaction recovery service having ownership of the transaction log; second performing recovery for the failed primary server, the recovery performed on the backup server; and third performing fallback migration of the transaction recovery service from the back-up server to the primary server.

2. The method of claim 1 wherein said first performing failover migration includes: initiating failover migration by an administrator.

3. The method of claim 2 wherein said initiating failover migration by an administrator includes an administrator issuing a migration command.

4. The method of claim 1 wherein the back-up server has multiple transaction recovery services residing on the back-up server, each transaction recovery service corresponding to a different primary server and a corresponding transaction log.

5. The method of claim 1 wherein said first performing failover migration includes: detecting that the primary server has failed; moving the transaction recovery service to the back-up server; and activating the transaction recovery service on the back-up server.

6. The method of claim 1 wherein said second performing recovery for the failed primary server includes: reading the transaction log of the primary server by the transaction recovery service while the transaction recovery service resides in the back-up server; and enabling the back-up server to read and coordinate transactions from the primary server's transaction log.

7. The method of claim 1 wherein said third performing fallback migration includes: initiating fallback migration of the transaction recovery service to the primary server; and completing fallback migration of the transaction recovery service to the primary server.

8. The method of claim 7 wherein said initiating fallback migration includes: detecting the startup of the primary server.

9. The method of claim 7 wherein said completing fallback migration includes: deactivating the transaction recovery service on the back-up server; moving the transaction recovery service from the back-up server to the primary server; and activating the transaction service on the primary server.

10. The method of claim 7 wherein said completing fallback migration includes moving the transaction recovery service from the back-up server to the primary server before primary server transaction recovery is complete.

11. The method of claim 7 wherein said completing fallback migration includes moving the transaction recovery service from the back-up server to the primary server after primary server transaction recovery is complete.

12. The method of claim 1 wherein said first performing failover migration is done automatically without user input, said second performing recovery is done automatically without user input, and said third performing fallback migration is done automatically without user input.

13. A method for performing transaction recovery comprising: (a) detecting a first server is down, the first server having a first transaction log on a memory and a first transaction recovery service;

(b) moving the first transaction recovery service to a second server;

(c) activating the first transaction recovery service on the second server;

(d) performing transaction recovery on behalf of the first server by the first transaction recovery service while the first transaction recovery service resides on the second server;

(e) deactivating the first transaction recovery service on the second server;

(f) moving the first transaction recovery service to the first server; and (g) activating the first transaction recovery service on the first server.

14. The method as claimed in claim 13 wherein said (b) moving the first transaction recovery service to a second server is initiated by a user.

15. The method as claimed in claim 13 further comprising step (h) completing transaction recovery on behalf of the first server by the first transaction recovery service, said completing transaction recovery occurring between steps (d) and (e).

16. The method as claimed in claim 13 further comprising step (i) initiating restart of the first server before transaction recovery on behalf of the first server is complete, step (i) occuring between steps (d) and (e), wherein deactivating the first transaction recovery service is performed before completing transaction recovery.

17. A transaction recovery system comprising: a first server instance having a first transaction recovery service, the first fransaction recovery service owning a first transaction log corresponding to said first server; a second server instance having a second transaction recovery service, the second transaction recovery service owning a second transaction log corresponding to said second server; and a shared memory, the first transaction log and the second transaction log residing on the shared memory, the first transaction recovery service configured to failover migrate from said first server instance to said second server instance if said first server fails[goes down], said second server instance configured to coordinate transactions from the first transaction log upon the failover migration of the first transaction recovery service.

18. The transaction recovery system of claim 17 wherein said second server instance is configured to receive more than one transaction recovery service.

19. The transaction recovery system of claim 17 further including an input apparatus, the input apparatus operable to allow a user to input a migrate command to initiate the failover migration.

20. The transaction recovery system of claim 17 further comprising a migratable framework, the transaction recovery service, said first server instance, and said second server instance configured to operate in conjunction with the migratable framework.

21. The transaction recovery system of claim 17 wherein said first server instance, said second server instance, and said shared memory reside on a single cluster.

22. The transaction recovery system of claim 17 wherein said first transaction recovery service is configured to be moved from said first server instance to said second server instance and activated on said second server instance.

23. The transaction recovery system of claim 17 wherein the first transaction recovery service is configured to fallback migrate from said second server instance to said first server instance upon detecting the startup of said server instance startup.

24. The fransaction recovery system of claim 23 wherein said first transaction recovery service is configured to be deactivated, moved from the second server instance to the first server instance, and activated on the first server instance.

25. The method of claim 3 wherein the issuing a migration command includes a user manually issuing a migration command using a console implemented as a GUI system.

26. The method of claim 3 wherein the issuing a migration command includes a user manually issuing a migration command using a command line.

27. The method of claim 3 wherein the issuing a migration command includes a user manually issuing a migration command using a JMX MBean.

28. The method as claimed in claim 4 wherein the backup server includes its own transaction recovery service, wherein the backup server's transaction recovery service functions as usual during migration failover and fallback.

29. The method of claim 13 wherein the second server includes a second transaction log, access to the memory, and a second transaction recovery service.

30. The method of claim 5 wherein moving the transaction recovery service to the back-up server includes manually issuing a migration command by a user.

31. The method of claim 5 wherein moving the transaction recovery service to the back-up server includes automatically moving the transaction recovery service to the back-up server by a migration service framework.

32. The method of claim 5 wherein the transaction recovery service is registered with the migration service framework.

33. The method as claimed in claim 7 wherein initiating fallback migration includes completing recovery for the primary server.

34. The method as claimed in claim 14 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a console implemented as a GUI system.

35. The method as claimed in claim 14 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a command line.

36. The method as claimed in claim 14 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a JMX MBean.

37. The transaction recovery system as claimed in claim 19 wherein the input apparatus includes an input configured to be used with a GUI system, wherein a user manually issues a migration command using a GUI system.

38. The transaction recovery system as claimed in claim 19 wherein the input apparatus includes a keyboard, wherein a user manually issues a migration command by entering a command on a command line.

39. The transaction recovery system as claimed in claim 19 wherein the input apparatus includes a keyboard, wherein a user manually issues a migration command by using a JMX MBean. P T/US03/04071

41

40. The transaction recovery system as claimed in claim 20 wherein the migratable framework is configured to automatically failover migrate the first transaction recovery service from said first server to said second server.

41. The transaction recovery system as claimed in claim 20 wherein the migratable framework is configured to automatically fallback migrate the first transaction recovery service from said second server to said first server when said second server has completed coordinating transactions from the first transaction log.

42. The transaction recovery system as claimed in claim 20 wherein the migratable framework is configured to automatically fallback migrate the first transaction recovery service from said second server to said first server when said first server has restarted.

43. A method for manually performing failover migration from a failed primary server to a backup server comprising: manually migrating a TRS from a failed primary server to a backup server; calling a JAVA method of the TRS while the TRS resides on the backup server, the JAVA method configured to activate the TRS on the backup server; reading the primary server's TLOG files by the TRS; instantiating and placing transactions in the backup server's transaction map by the TRS; and performing recovery for the primary server on the backup server by the

TRS, recovery including driving prepared transactions to completion and performing resource recovery.

44. A method for manually performing failback migration from a backup server to a primary server after recovery on a primary server is complete comprising: completing recovery for a failed primary server by a TRS associated with the primary server and residing on the backup server; requesting a migratable framework to migrate the TRS from the backup server to the primary server, the backup server making the request to the migratable framework; deactivating the TRS residing on the backup server by the migratable framework, wherein deactivating the TRS includes the migratable framework calling a JAVA method residing in the TRS to deactivate the TRS on the backup server; and migrating the TRS from the backup server to the primary server by the migratable framework, wherein the primary server regains ownership of a TLOG conesponding to the primary server upon primary server restart.

45. A method for manually performing failback migration from a backup server to a primary server before recovery on a primary server is complete comprising: performing recovery for a failed primary server by a TRS associated with the primary server and residing on the backup server; notifying the backup server that the primary server has restarted, the notification including an administrative MBean; requesting a migratable framework to migrate the TRS from the backup server to the primary server, the TRS making the request to the migratable framework; deactivating the TRS residing on the backup server by the migratable framework, wherein deactivating the TRS includes the migratable framework calling a JAVA method residing in the TRS to deactivate the TRS on the backup server; and migrating the TRS from the backup server to the primary server by the migratable framework, wherein upon a primary server restart, the primary server regains ownership of a TLOG corresponding to the primary server and completes recovery of the primary server.

46. The method of claim 45 wherein deactivating the TRS includes the TRS suspending recovery processing for the primary server, checkpointing the TLOG for the primary server, purging transactions in the transaction map of the backup server that originated from the TLOG of the primary server, and ending resource recovery perfonned for the primary server.

47. A method for automatically performing failover migration from a failed primary server to a backup server comprising: detecting the failure of a primary server by a migratable framework; migrating a TRS associated with the primary server from the failed primary server to a backup server, said migrating a TRS including deactivating the TRS on the primary server by calling an MBean method of the TRS by the migratable framework; activating the TRS on the backup server, said activating the TRS including reading a TLOG of the primary server, instantiating transactions from the TLOG and moving them to the transaction map of the backup server, and scheduling resource recovery for the failed primary server; and performing recovery for the primary server by the TRS while the TRS resides on the backup server, said performing recovery including driving prepared transactions to completion and performing resource recovery.

48. A method for automatically performing failback migration from a backup server to a primary server after recovery performed on a primary server is complete, the method comprising: completing recovery for a primary server by a TRS associated with the primary server, the TRS completing recovery for the primary server while the TRS resides on a backup server, said completing recovery including the TRS checkpointing a TLOG associated with the primary server and relinquishing control of the TLOG of the primary server; initiating migration of the TRS from the backup server to the primary server, said initiating migration of the TRS including the backup server requesting the migratable framework to migrate the TRS to the primary server; deactivating the TRS on the backup server, said deactivating the TRS including calling an MBean method of the TRS by the migratable framework; and migrating the TRS from the backup server to the primary server by the migratable framework, wherein the primary server regains TLOG ownership upon primary server startup.

49. A method for automatically performing failback migration from a backup server to a primary server before recovery performed on a primary server is complete, the method comprising: restarting a primary server, wherein performing recovery on the primary server is not completed by a TRS residing on the backup server before the primary server is restarted; initiating migration of a TRS associated with a primary server from a backup server to the primary server, said initiating migration including detecting the startup of the primary server by a migratable framework; deactivating the TRS residing on the backup server, said deactivating including calling a JAVA method of the TRS to deactivate the TRS, the method configured to: checkpoint a TLOG associated with the primary server; purging transactions in the transaction map of the backup server that originated from the

TLOG of the primary server; and stopping resource recovery being performed for the primary server; migrating the TRS to the primary server; and activating the TRS on the primary server, said activating the TRS including calling a JAVA method of the TRS to activate the TRS, wherein the primary server regains ownership of the TLOG and performs recovery as required.

50. The method of claim 1 wherein said fransaction recovery service is a JAVA server instance. ^•

51. The method of claim 50 wherein each transaction recovery service is associated with a JAVA element that indicates an alternate server as a migratable target for the transaction recovery service, wherein a user may specify the alternate server withing the JAVA method.

52. The method of claim 50 wherein a first JAVA MBean conesponds to each of the backup server and the primary server, each first MBean including runtime information regarding the transaction recovery system instances hosted by the conesponding backup server or primary server.

53. The method of claim 52 wherein the first MBean includes a first JAVA method that returns whether a transaction recovery service instance is cunently activated on a particular server.

54. The method of claim 52 wherein perfonning recovery on a failed server includes reading transactions from a transaction log by the transaction recovery service relating to the failed server, the transaction log conesponding to the failed server, wherein the first MBean includes a second JAVA method configured to return the total number of fransactions read from the transaction log by the transaction recovery service.

55. The method of claim 52 wherein the first MBean includes a third JAVA method that returns the percentage of the recovered fransactions that are completed by the transaction recovery service.

56. The method of claim 52 wherein a second MBean may access the runtime information of each first MBean.

57. The method of claim 56 wherein the second MBean includes a fourth JAVA method that returns an anay of MBeans conesponding to the transaction recovery service instances deployed on a server.

58. The method of claim 56 wherein the second MBean includes a fifth JAVA method that returns the first MBean.

59. The method of claim 5 wherein moving the transaction recovery service to the back-up server is implemented by a command line administration tool implemented as a JAVA program.

60. The method of claim 5 wherein moving the transaction recovery service to the back-up server is implemented by a JAVA MBean.

61. The method of claim 1 wherein said transaction recovery service is a server instance implemented in Java.

62. The method of claim 13 wherein said transaction recovery service is a server instance implemented in Java.

63. The method of claim 17 wherein said first transaction recovery service and second transaction recovery service are each a server instance implemented in java.

64. A method for performing transaction recovery within a cluster comprising: performing failover migration fo a transaction recovery service from a failed primary server to a backup server, the transaction recovery service implemented as a java instance and owning a transaction log conesponding to the primary server; activating the transaction recovery service on the backup server by the migratable framework, the migratable framework opearable to call an activation method of the transaction recovery service, the activation method implemented in java, activating the transaction recovery service including: reading the transaction log of the primary server; placing primary server transaction files in a transaction map of the backup server; and scheduling resource recovery for the primary server; performing transaction recovery on behalf of the failed primary server by the transaction recovery service, transaction recovery including driving prepared transactions to completion and performing resource recovery; initiating migration from the backup server to the primary server upon the occunence of an event; and performing failback migration of the transaction recovery service from the backup server to the primary server, failback migration including: deactivating the transaction recovery service on the backup server by the migratable framework, the migratable framework operable to call a deactivation method of the transaction recovery service, the deactivation method implemented in java; migrating the transaction recovery service to the primary server; and activating the transaction recovery service on the primary server by calling the activation method.

65. The method of claim 64 wherein the event is the completion of the recovery performed on behalf of the primary server.

66. The method of claim 64 wherein the event is the restart of the primary server.

67. The method of claim 1 wherein the failover migration, recovery, and failback migration provide highly available fransaction recovery and improve the availability of the server.

68. The method of claim 13 wherein the method for performing transaction recovery provide highly available transaction recovery and improve the availability of the server.

69. The system of claim 16 wherein the transaction recovery system is configured to provide highly available transaction recovery and improve the availability of the server.

70. The method of claim 64 wherein the method for performing transaction recovery in a cluster provides highly available transaction recovery and improve the availability of the server.

71. A method for recovering transactions comprising: performing failover migration of a transaction recovery service from a failed primary server to a backup server, the primary server having a transaction log, and the transaction recovery service having ownership of the log; and allowing the backup server to read the fransaction log and perform recovery on behalf of the failed server.

72. The method of claim 71 including the step of: performing recovery on the primary server.

73. The method of claim 72 including the step of: perfonning failback migration of the transaction recovery service from the backup server to the primary server.

74. The method of claim 71 wherein said primary server and the backup server are in a cluster.

75. The method of claim 71 wherein transaction recovery is accomplished automatically.

76. The method of claim 71 wherein transaction recovery is accomplished manually.

77. The method of claim 71 wherein transaction recovery is accomplished manually by an administrator.

78. The method of claim 71 including a migratable service framework and wherein said transaction recovery service depends upon the migratable service framework for manual migration support.

79. The method of claim 71 including a migratable service framework and wherein said transaction recovery service depends upon the migratable service framework for automatic migration support.

80. The method of claim 71 wherein said transaction recovery service is a server instance implemented in java.

81. The method of claim 71 wherein said transaction recovery service is manually migrated and monitored by one of an adminisfration console and a

JMX API.

82. A system for recovering fransactions comprising: a primary server having a transaction log, wherein a first transaction recovery service maintains ownership of the transaction log; and a backup server, wherein upon a failure of the primary server, the first transaction recovery service is configured to failover migrate from the primary server to the back-up server, the backup server operable to read the transaction log and perform recovery on behalf of the failed primary server while the backup server hosts the first transaction recovery service.

83. The system of claim 82 wherein the transaction recovery service is configured to failback migrate from the backup server to the primary server.

84. The system of claim 83 wherein the transaction recovery service is configured to initiate failback migration after performing recovery on the primary server is complete.

85. The system of claim 83 wherein the transaction recovery service is configured to initiate failback migration after the primary server has restarted.

86. The system of claim 82 wherein the primary server and backup server reside in a cluster.

87. The system of claim 82 wherein transaction recovery is accomplished automatically.

88. The system of claim 82 wherein transaction recovery is accomplished manually.

89. The system of claim 82 wherein transaction recovery is accomplished manually by an administrator.

90. The system of claim 82 further comprising a migratable framework, the transaction recovery service configured to receive support from the migratable service framework for manual migration.

91. The system of claim 82 further comprising a migratable framework, the transaction recovery service configured to receive support from the migratable service framework for automatic migration.

92. A cluster of servers configured to provide transaction recovery comprising: a primary server having a transaction log, wherein a transaction recovery service maintains ownership of the transaction log, the primary server and transaction log residing in the cluster; a backup server residing in the cluster and having access to the transaction log, the transaction recovery service configured to failover migrate from the primary server to the back-up server upon failure of the primary server, the backup server operable to read the transaction log and perfonn recovery on behalf of the failed primary server while the backup server hosts the first transaction recovery service.

93. The cluster of servers of claim 92 wherein the transaction recovery service is configured to failback migrate from the backup server to the primary server.

94. The cluster of servers of claim 93 wherein the transaction recovery service is configured to initiate failback migration after performing recovery on the primary server is complete.

95. The cluster of servers of claim 93 wherein the transaction recovery service is configured to initiate failback migration after the primary server has restarted.

96. The cluster of servers of claim 92 wherein transaction recovery is accomplished automatically.

97. The cluster of servers of claim 92 wherein transaction recovery is accomplished manually by an administrator.

98. The cluster of servers of claim 92 further comprising a migratable framework, the migratable framework residing in the cluster, the transaction recovery service configured to receive support from the migratable service framework for manual migration.

99. The cluster of servers of claim 92 further comprising a migratable framework, the migratable framework residing in the cluster, the transaction recovery service configured to receive support from the migratable service framework for automatic migration.

100. In a cluster of servers, a server high availability method comprising the step of performing transaction recovery in a backup server using a transaction recovery service and a transaction log stored in a memory shared between the backup server and a failed server before the step of restating the failed server.

101. In a cluster of servers, a server high availability method comprising the step of performing transaction recovery in a backup server using a fransaction recovery service and a transaction log before the step of restating a failed server.