Transaction recovery in a transaction processing computer system employing multiple transaction managers

Patent metadata

Field	Value
Publication number	US-10360113-B2
Application number	US-201514887229-A
Country	US
Kind code	B2
Filing date	Oct 19, 2015
Priority date	Dec 11, 2009
Publication date	Jul 23, 2019
Grant date	Jul 23, 2019

Abstract

A technique for transaction recovery by one transaction manager of another transaction manager's transactions in which each transaction manager is adapted to manage two phase commit transactional operations on transactional resources and to record commit or rollback decisions in a transaction recovery log. The recovery transaction manager detects apparent unavailability of the another transaction manager for transaction processing and initiates a transaction recovery process for the another transaction manager's transactions. This process also determines whether any of the transactions of the another transaction manager have all respective resources prepared to commit without there yet being a pending commit decision record in the another transaction manager's recovery log. If so, the recovery transaction manager writes a rollback record indicating an intention to roll back the identified transaction, in the another transaction manager's recovery log provided no commit decision record has been recorded.

First claim

What is claimed is:

1. A method of transaction recovery by one transaction manager of transactions associated with another transaction manager in a transaction processing computer system in which both said transaction manager and said another transaction manager are adapted to manage two phase commit transactional operations on transactional resources and to record commit or rollback decisions in a respective transaction recovery log, each of the transaction resources being managed by a resource manager that is operable to record a prepared status of a given resource to commit changes defined by a transaction, the method comprising steps of:
said one transaction manager detecting apparent unavailability of said another transaction manager for transaction processing;
in response to such detection, said one transaction manager initiating a transaction recovery process for said transactions associated with said another transaction manager, said transaction recovery process including steps of:
determining whether any of the transactions of said another transaction manager have all respective resources prepared to commit without there yet being a pending commit decision record in a transaction recovery log of said another transaction manager and, if such a transaction is identified, writing a rollback record indicating an intention to roll back the identified transaction in said transaction recovery log of said another transaction manager if no commit decision record has been recorded subsequent to said determining step.

2. The method as claimed in claim 1 , wherein if said another transaction manager is available for transaction processing, said another transaction manager is allowed to write a commit decision record in said transaction recovery log of said another transaction manager provided there is no rollback record for the same transaction already in said transaction recovery log of said another transaction manager.

3. The method as claimed in claim 1 in which said detection step comprises monitoring for loss of heartbeat signals transmitted by said another transaction manager.

4. The method as claimed in claim 2 in which the respective transaction recovery logs are tables in a database with individual transaction records being identified by keys, and further comprising a step of preventing writing of said commit and rollback decision records if a record using a same key already exists.

5. The method as claimed in claim 2 further comprising a step of shutting down said another transaction manager if said another transaction manager is not allowed to write the commit decision record to its transaction recovery log for the identified transaction.

6. The method as claimed in claim 2 further comprising a step of causing said one transaction manager, in the event that its attempt to write the rollback record for said identified transaction is rejected because there is already a commit record for said transaction in said transaction recovery log for said another transaction manager, to attempt to commit prepared resource changes defined by said transaction.

7. A non-transitory computer usable medium comprising a computer program stored thereon, where the computer program is operable for transaction recovery in a transaction processing computer system, the computer program comprising instructions which, when executed in the computer system, causes said computer system to carry out the steps of the method as claimed in claim 1 .

8. A data processing system comprising a data processor and a transaction manager configured to recover transactions associated with another transaction manager in a transaction processing computer system in which said transaction manager and said another transaction manager are adapted to manage two phase commit transactional operations on external transactional resources and to record commit or rollback decisions in a transaction recovery log, each of the transaction resources being managed by a resource manager effective to record a prepared status of the resource to commit changes defined by a transaction; said transaction manager comprising program code that is stored on a non-transitory computer-usable storage device and is operable when executed by the data processor to perform steps of:
detecting apparent unavailability of said another transaction manager for transaction processing;
determining, responsive to said detecting, whether any of the transactions of said another transaction manager have all respective resources prepared to commit without there yet being a pending commit decision record in a transaction recovery log of said another transaction manager and writing, responsive to said determining, a rollback record indicating an intention to roll back the identified transaction in said transaction recovery log of said another transaction manager if no commit decision record has been recorded subsequent to said determination.

9. The data processing system as claimed in claim 8 , wherein if said another transaction manager is available for transaction processing, said another transaction manager is allowed to write a commit decision record in said transaction recovery log of said another transaction manager provided there is no rollback record for the same transaction already in said transaction recovery log of said another transaction manager.

10. The data processing system as claimed in claim 8 in which said detecting unavailability is adapted to monitor for loss of heartbeat signals transmitted by said another transaction manager.

11. The data processing system as claimed in claim 9 further comprising a database in which the respective transaction recovery logs are tables in which individual transaction records are identified by keys, and further comprising program code for preventing writing of said commit and rollback decision records if a record using a same key already exists.

12. The data processing system as claimed in claim 9 further comprising program code for shutting down said another transaction manager if it is not allowed to write the commit decision record to the transaction log for the identified transaction.

13. The data processing system as claimed in claim 8 further comprising program code for causing said transaction manager, if its attempt to write the rollback record for said identified transaction is rejected because there is already a commit record for said transaction in said transaction recovery log of said another transaction manager, to attempt to commit the prepared resource changes defined by said transaction.

14. The data processing system as claimed in claim 9 in which said transaction manager and said another transaction manager are peers in a cluster of transaction managers, and further comprising program code for designating one of said transaction manager and another transaction manager as a recovery transaction manager in response to detection of apparent unavailability of the other of the transaction manager and the another transaction manager.

15. The method as claimed in claim 1 , wherein the rollback record is written in said transaction recovery log of said another transaction manager by said one transaction manager.

16. The computer program of claim 7 , wherein the rollback record is written in said transaction recovery log of said another transaction manager by said one transaction manager.

17. The data processing system as claimed in claim 8 , wherein the rollback record is written in said transaction recovery log of said another transaction manager by said transaction manager.

18. The me

Assignees

• IBM

Inventors

• Maple Simon J
• Robinson Ian

Classifications

• G06F11/2028 Primary

  eliminating a faulty processor or activating a spare · CPC title

• G06F16/2365

  Ensuring data consistency and integrity · CPC title

• G06F16/2379

  Updates performed during online database operations; commit processing · CPC title

• G06F2201/84

  Using snapshots, i.e. a logical point-in-time copy of the data · CPC title

• G06F16/256

  in federated or virtual databases · CPC title