System and method for persisting transaction records in a transactional middleware machine environment

• US 9,110,851 B2
• Filed: 03/07/2012
• Issued: 08/18/2015
• Est. Priority Date: 09/29/2011
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Little, Todd, Li, Xiangdong, Lv, Xianzheng
• Primary Examiner(s): BUTLER, SARAI E
• Application Number:
  US13/414,607
• Publication Number:
  US 20130086419A1
• Time in Patent Office: 1,259 Days
• Field of Search: 714/4.11, 714/45, 714/48, 714/20
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 11/2038 with a single idle spare processing component
• CPC Class Codes: G06F 11/2043 where the redundant components share a common memory address space
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 2201/80 Database-specific techniques

Abstract

A transactional system can utilize the distributed storage and high availability (HA) capability provided by a clustered database to support easy and feasible disaster recovery. The transactional middleware machine environment comprises one or more transactional application servers associated with a transaction. The one or more transactional application servers operate to persist transactional log information associated with the transaction in a database that connects with said one or more transactional application servers at a local site. The database at the local site operates to replicate the persisted transactional log information to a remote database at a remote site. The remote database allows a different transactional application server at the remote site to recover the persisted transactional log information and complete the transaction, when a disaster disables the local site.

Claims

1. A method for supporting disaster recovery in a transactional middleware machine environment, comprising:

providing a clustered database accessible to a plurality of application servers wherein the clustered database provides a coordinated set of data across a distributed plurality of database servers, wherein the clustered database operate to replicate said set of data across said plurality of database servers;

providing a connection from each application server to said clustered database, whereby an application operating on said application server can

read data, over said connection, from said set of data for commencing a transaction,

process said data, and

write processed data, over said connection, to said set of data for completing a transaction;

defining a plurality of different transaction logs, by defining for each application server of the plurality of application servers, a transaction log comprising a plurality of log records of transactions in process on said application server;

persisting, the plurality of different transaction logs to said clustered database over said connection from each application server to said clustered database;

replicating each of said plurality of different transaction logs across said plurality of database servers by using the clustered database to generate a plurality of replica different transaction logs wherein each of said plurality of different transaction logs is associated with at least one replica different transaction log stored at a site remote from the associated different transaction log; and

when a disaster disables a first application server having a first transaction log of said plurality of different transaction logs associated with a first replica transaction log of said plurality of replica different transaction logs stored at a site remote from the first transaction log, allowing a second application server at a site remote from the first application server to recover the first replica transaction log of said plurality of replica different transaction logs from one of said plurality of database servers and complete transactions identified in said first replica transaction log.

2. The method of claim 1, further comprising:

defining the plurality of different transaction logs in a universal device list comprising a map of a transactional file system.

3. The method of claim 1, further comprising:

defining the plurality of different transaction logs in a universal device list (UDL) comprising a map of a transactional file system wherein the UDL is loaded into a shared memory when an application is booted.

4. The method of claim 1, further comprising providing an application programming interface (API) for persisting, the transaction log of each application server, to said clustered database over said connection from each application server to said clustered database.

5. The method of claim 1, further comprising providing an application programming interface for persisting, the transaction log of each application server, to said clustered database over said connection from each application server to said clustered database and providing a configuration file which invokes said (API).

6. The method of claim 1, wherein persisting the transaction log over said connection avoids creation of additional concurrent database connections for persisting the transaction log.

7. The method of claim 1, wherein each transaction is a two-phase transaction.

8. The method of claim 7, further comprising allowing the transaction log to contain persist state of a transaction manger after successfully committing a first phase of the two-phase transaction.

9. The method of claim 1, further comprising:

providing a transaction processing monitor (TPM) which establishes said connection.

10. A system supporting disaster recovery in a transactional middleware machine environment, comprising:

a clustered database accessible to a plurality of application servers wherein the clustered database provides a coordinated set of data across a distributed plurality of database servers, wherein the clustered database operate to replicate said set of data across said plurality of database servers;

a connection from each application server to said clustered database, whereby an application operating on said application server can

read data, over said connection, from said set of data for commencing a transaction,

process said data, and

write processed data, over said connection, to said set of data for completing a transaction;

a plurality of different transaction logs comprising a separate transaction log for each particular application server comprising a plurality of log records of transactions in process on said each particular application server;

wherein the each particular application server persists the separate transaction log associated with said each particular application server to said clustered database over said connection from said particular application server to said clustered database;

wherein the clustered database operates to replicate each of said plurality of different transaction logs across said plurality of database servers by using the clustered database to generate a plurality of replica different transaction logs wherein each of said plurality of different transaction logs is associated with at least one replica different transaction log stored at a site remote from the associated different transaction log; and

wherein, when a disaster disables a first particular application server having a first separate transaction log and associated with a first separate replica transaction log stored at a site remote from the first separate transaction log, a second application server at a site remote from the first particular application server is configured to recover the first separate replica transaction log from one of said plurality of database servers and complete transactions identified in said first separate replica transaction log.

11. The system of claim 10, wherein:

the separate transaction log of each particular application server is defined in a universal device list comprising a map of a transactional file system.

12. The system of claim 10, wherein:

the separate transaction log of each particular application server is defined in a universal device list (UDL) comprising a map of a transactional file system and wherein the UDL is loaded into a shared memory when an application is booted.

13. The system of claim 10, further comprising:

an application programming interface (API) for persisting, the separate transaction log of each particular application server, to said clustered database over said connection from each particular application server to said clustered database.

14. The system of claim 10, further comprising:

an application programming interface for persisting, the separate transaction log of each particular application server, to said clustered database over said connection from each particular application server to said clustered database; and

a configuration file which invokes said (API).

15. The system of claim 10, wherein persisting the transaction log over said connection avoids creation of additional concurrent database connections for persisting the transaction log.

16. The system of claim 10, wherein each transaction is a two-phase transaction.

17. The system of claim 16, wherein the separate transaction log of each particular application server contains persist state of a transaction manger after successfully committing a first phase of the two-phase transaction.

18. The system of claim 10, further comprising:

a transaction processing monitor (TPM) which establishes said connection.

19. A non-transitory computer readable storage medium including instructions stored thereon for supporting disaster recovery in a transactional middleware machine environment, which instructions, when executed by a computer, cause the computer to perform steps comprising:

providing a clustered database accessible to a plurality of application servers wherein the clustered database provides a coordinated set of data across a distributed plurality of database servers, wherein the clustered database operate to replicate said set of data across said plurality of database servers;

providing a connection from each application server to said clustered database, whereby an application operating on said application server can

read data, over said connection, from said set of data for commencing a transaction,

process said data, and

write processed data, over said connection, to said set of data for completing a transaction;

defining a plurality of different transaction logs, by defining for each application server of the plurality of application servers, a transaction log comprising a plurality of log records of transactions in process on said application server;

persisting, the plurality of different transaction logs to said clustered database over said connection from each application server to said clustered database;

replicating each of said plurality of different transaction logs across said plurality of database servers by using the clustered database to generate a plurality of replica different transaction logs wherein each of said plurality of different transaction logs is associated with at least one replica different transaction log stored at a site remote from the associated different transaction log; and

when a disaster disables a first application server having a first transaction log of said plurality of different transaction logs associated with a first replica transaction log of said plurality of replica different transaction logs stored at a site remote from the first transaction log, allowing a second application server at a site remote from the first application server to recover the first replica transaction log of said plurality of replica different transaction logs from one of said plurality of database servers and complete transactions identified in said first replica transaction log.

20. The non-transitory computer readable storage medium of claim 19, including further instructions stored thereon, which, when executed by a computer, cause the computer to perform further steps comprising:

defining the plurality of different transaction logs in a universal device list comprising a map of a transactional file system.