Hybrid method for flushing transaction state in a fault-tolerant clustered database

1. A method of performing a transaction in a processing cluster having a plurality of processing units, one of the processing units hosting a transaction monitor, at least one processing unit hosting a resource manager, each of the processing units including a CPU and volatile storage and having access to stable storage, the method comprising:

beginning a transaction by the transaction monitor, and

performing the following steps if no processing unit failure occurs:

registering one or more resource managers to participate in the transaction, the processing units hosting the participating resource managers being participating processing units;

performing work required by the transaction by the one or more participating resource managers, including obtaining any locks needed by the transaction;

upon completion of the transaction work by the participating resource managers, performing a phase 1 operation in which a flush request is broadcast to each participating processing unit, the flush request instructing each participating processing unit to send a response indicating that information in volatile storage is flushed to stable storage;

upon completion of the phase 1 operation, requesting a phase 2 operation by broadcasting a lock-release request to each participating processing unit, except the processing unit hosting the transaction monitor;

releasing any locks acquired for the transaction while performing work required by the transaction in response to the phase 2 request; and

after releasing all locks acquired for the transaction, informing the transaction monitor that phase 2 is completed; and

wherein if a failure occurs during a phase 2 operation,

requesting a phase 2 operation in which a release-lock request is broadcast to each processing unit, except the processing unit hosting the transaction monitor;

releasing any locks acquired for the transaction while performing work required by the transaction; and

after releasing all locks acquired for the transaction, informing the transaction monitor that the transaction is completed.

2. A method of performing a transaction as recited in claim 1 ,

wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor; and

further comprising the step of informing the backup transaction monitor of the beginning 30 of the transaction prior to performing the registering step.

3. A method of performing a transaction as recited in claim 1 ,

wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor; and

wherein the primary transaction monitor receives a response that all processing units are flushed prior to the completion of the phase 1 operation.

4. A method of performing a transaction as recited in claim 1 ,

wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor;

wherein the primary transaction monitor receives a message requesting the transaction monitor process pair to release locks, after all participating processing units, except the processing units hosting the transaction monitor process pair, have completed a phase 2 lock release operation; and

further comprising the step of performing, in response to the message, a phase 2 lock release operation by the transaction monitor process pair.

5. A method of performing a transaction as recited in claim 1 ,

wherein the resource manager is implemented as a process pair that includes a primary and backup resource manager; and

wherein the step of registering one or more resource managers to participate in the transaction includes registering the primary and backup resource manager.

6. A method of performing a transaction as recited in claim 1 ,

wherein the resource manager is implemented as a process pair that includes a primary and backup resource manager; and

wherein the step of performing a phase 1 flush operation includes performing a phase 1 flush operation by each of the primary and backup resource managers.

7. A method of performing a transaction as recited in claim 1 ,

wherein the resource manager is implemented as a process pair that includes a primary and backup resource manager; and

wherein the step of releasing any locks includes releasing, by each of the primary and backup resource managers, any locks acquired by the primary and backup resource managers.

8. A method of performing a transaction as recited in claim 1 , the method further comprising:

if a failure occurs during a phase 1 operation,

performing a phase 1 operation in which a flush request is broadcast to each processing unit, the flush request instructing each processing unit working behalf of the transaction to send a response indicating that information in volatile storage is flushed to stable storage and instructing processing units not working on behalf of the transaction to so indicate; and

upon completion of the phase 1 operation, performing the procedure consequent to failure during a phase 2 operation.

9. A method of performing a transaction as recited in claim 8 , the method further comprising:

if a failure occurs during registering,

broadcasting a begin transaction message to all processing units, accept the unit hosting the transaction monitor; and

upon completion of said registering, performing the procedure consequent to failure during a phase 1 operation.

10. A method of performing a transaction in a processing cluster having a plurality of processing units, one of the processing units hosting a transaction monitor, at least one processing unit hosting a resource manager, each of the processing units inducing a CPU and volatile storage and having access to stable storage, the method comprising:

beginning a transaction by the transaction monitor,

broadcasting a begin transaction message to all processing units, except the unit hosting the transaction monitor;

performing work required by the transaction by the one or more resource managers working on behalf of the transaction, including obtaining any locks needed by the transaction;

upon completion of the transaction work by the resource managers working on behalf of the transaction, during a phase 1 operation in which a flush request as broadcast to each processing unit, the flush request instructing each processing unit working behalf of the transaction to send a response indicating that information in volatile storage is flushed to stable storage and instructing processing units not working on behalf of the transaction to so indicate;

upon completion of the phase 1 operation, requesting a phase 2 operation in which a release-lock request is broadcast to each processing unit, except the processing unit hosting the transaction monitor;

releasing any locks acquired for the transaction while performing work required by the transaction; and

after releasing all locks acquired for the transaction, informing the transaction monitor that phase 2 is completed.

11. A method of performing a transaction in a processing duster having a plurality of processing units, one of the processing units hosting a transaction monitor, at least one processing unit hosting an application program and a resource manager, each of the processing units including a CPU and volatile storage and having access to stable storage, the method comprising:

beginning a transaction by the application program;

informing the transaction monitor that a transaction is begun; and

performing the following steps if no processing unit failure occurs;

registering one or more resource managers to participate in the transaction, the processing units hosting the participating resource managers being participating processing units;

performing work required by the transaction by the one or more participating resource managers, inducting obtaining any locks needed by the transaction;

upon completion of the transaction work by the participating resource managers, performing a phase 1 operation in which a flush request is broadcast to each participating processing unit, the flush request instructing each participating processing unit to send a response indicating that information in volatile storage is flushed to stable storage;

upon completion of the phase 1 operation, requesting a phase 2 operation by broadcasting a lock-release request to each participating processing unit, except the processing unit hosting the transaction monitor;

releasing any locks acquired for the transaction while performing work required by the transaction in response to the phase 2 request; and

after releasing all locks acquired for the transaction, informing the transaction 30 monitor that phase 2 is completed; and

if a failure occurs during a phase 2 operation,

requesting a modified phase 2 operation in which a release-lock request is broadcast to each processing unit, except the processing unit hosting the transaction monitor;

releasing any locks acquired for the transaction while performing work required by the transaction; and

after releasing all locks acquired for the transaction, informing the transaction monitor that phase 2 is completed.

12. A method of performing a transaction as recited in claim 11 ,

wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor; and

further comprising the step of informing the backup transaction monitor of the beginning of the transaction prior to performing the registering step.

13. A method of performing a transaction as recited in claim 11 ,

wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor; and

wherein the primary transaction monitor receives a response that all processing units are flushed prior to the completion of the phase 1 operation.

14. A method of performing a transaction as recited in claim 11 , wherein the transaction monitor is implemented as a process pair that includes a primary and backup transaction monitor,

wherein the primary transaction monitor receives a message requesting the transaction monitor process pair to release locks, after all participating processing units, except the processing units hosting the transaction monitor process pair, have completed a phase 2 lock release operation; and

further comprising the step of performing, in response to the message, a phase 2 lock release operation by the transaction monitor process pair.

15. A method of performing a transaction as recited in claim 11 ,

wherein the resource manager is implemented as a process pair that includes a primary and backup resource manager; and

wherein the step of registering one or more resource managers to participate in the transaction includes registering the primary and backup resource manager.

16. A method of performing a transaction as recited in claim 11 ,

wherein the resource manager is implemented as a process pair that includes a primary and backup resource manager, and

wherein the step of performing a phase 1 flush operation includes performing a phase 1 flush operation by each of the primary and backup resource managers.

17. A method of performing a transaction as recited in claim 11 ,

wherein the resource manager is implemented as a process pair that includes a primary

and backup resource manager; and

wherein the step of releasing any locks includes releasing, by each of the primary and backup resource managers, any locks acquired by the primary and backup resource managers.

18. A method of performing a transaction as recited in claim 11 , the method further comprising:

if a failure occurs during a phase 1 operation,

performing a phase 1 operation in which a flush request is broadcast to each processing unit, the flush request instructing each processing unit working behalf of the transaction to send a response indicating that information in volatile storage is flushed to stable storage and instructing processing units not working on behalf of the transaction to so indicate;

upon completion of the phase 1 operation, performing said modified procedure consequent to failure during a phase 1 operation.

19. A method of performing a transaction as recited in claim 18 , the method further comprising:

if a failure occurs during registering,

broadcasting a begin transaction message to all processing units, except the unit hosting the transaction monitor; and

upon completion of said registering, performing said modified procedure consequent to failure during a phase 1 operation.

20. A processing duster comprising:

a stable storage system;

a plurality of processing units, each processing unit including a CPU and a volatile

memory in which data and programs reside, and configured to access the stable storage system, wherein a designated one of the processing units hosts a transaction monitor program and at least one processing unit hosts a resource manager program, wherein the transaction monitor is configured to begin a transaction, and if no processing unit failure occurs:

register one or more resource managers to participate in the transaction, the processing units hosting the participating resource managers being participating processing units;

cause the one or more participating resource managers to perform work required by the transaction, including obtaining any locks needed by the transaction;

upon completion of the transaction work by the participating resource managers, cause a phase 1 operation to be performed in which a flush request is broadcast to each participating processing unit, the flush request instructing each participating processing unit to send a response to the transaction monitor indicating that information in volatile storage is flushed to stable storage;

upon completion of the phase 1 operation, cause a phase 2 operation by broadcasting a lock-release request to each participating processing unit, except the processing unit hosting the transaction monitor, any locks acquired for the transaction while performing work required by the transaction being released in response to the phase 2 request; and receive a message indicating that phase 2 is completed; and

wherein the transaction monitor is further configured to:

if a failure occurs during a phase 2 operation,

cause a modified phase 2 operation to be performed in which a release-lock request is broadcast to each processing unit, except the processing unit hosting the transaction monitor, any locks acquired for the transaction while performing work required by the transaction being released in response to the release-lock request; and

receive a message that phase 2 is completed.

21. A processing cluster as recited in claim 20 , wherein the transaction monitor is further configured to:

if a failure occurs during a phase 1 operation,

cause a modified phase 1 operation to be performed in which a flush request is broadcast to each processing unit, the flush request instructing each processing unit working behalf of the transaction to send a response indicating that information in volatile storage is flushed to stable storage and instructing processing units not working on behalf of the transaction to so indicate;

upon completion of the phase 1 operation, causing said modified phase 2 operation to be performed.

22. A processing cluster as recited in claim 21 , wherein the transaction monitor is further configured to:

if a failure occurs during registering,

broadcast a begin transaction message to all processing units, except the unit hosting the transaction monitor;

cause the one or more resource managers to perform work required by the transaction on behalf of the transaction, including obtaining any locks needed by the transaction;

upon completion of the transaction work by the resource managers working on behalf of the transaction, cause a said modified phase 1 operation to be performed.