Mixed-mode method for combining active/active and validation architectures utilizing a check integrity module

• US 10,642,826 B1
• Filed: 07/24/2019
• Issued: 05/05/2020
• Est. Priority Date: 08/30/2018
• Status: Active Grant

• Current Assignee: Gravic Incorporated
• Original Assignee: Gravic Incorporated
• Inventors: Holenstein, Bruce D., Holenstein, Dylan R., Holenstein, Paul J.
• Primary Examiner(s): Boccio, Vincent F
• Application Number:
  US16/520,904
• Time in Patent Office: 286 Days
• Field of Search: 707703
• CPC Class Codes: G06F 16/2365 Ensuring data consistency and integrity
• CPC Class Codes: G06F 16/2379 Updates performed during online database operations; commit processing
• CPC Class Codes: G06F 16/273 Asynchronous replication or reconciliation

Abstract

A method is provided for performing transaction processing in a system that includes a transaction distributor and a plurality of nodes. Each of the nodes include a processor, an application executing in the processor, and an instance of a database used by the application. Each node executes transactions. The transaction distributor selects at least two of the nodes to receive the same request to process a transaction, and the processor at each of the at least two nodes executes the same request to process a transaction. Each of the at least two nodes replicates to one or more other nodes in the system the steps and operations of the transactions up until a transaction END step. A check integrity module determines if the transaction integrity should be checked. If so, the processor at the one or more other nodes compares the replicated steps and operations of the transactions that were received from each of the at least two nodes and performs a transaction END step for the replicated transaction at the one or more other nodes in the system by either executing a COMMIT when the result of the comparison indicates that the replicated steps and operations of the replicated transactions match each other, or executing an ABORT when the result of the comparison indicates that the replicated steps and operations of the replicated transactions do not match each other.

Claims

1. A method of performing transaction processing in a system, the system including a transaction distributor, at least one check integrity module, and a plurality of nodes, each node in the system including (i) a processor, (ii) an application executing in the processor, and (iii) an instance of a database used by the application, each node executing transactions, each transaction including a BEGIN step, one or more data manipulation language (DML) or data definition language (DDL) operations, and a transaction END step which is either a COMMIT or an ABORT, the method comprising:

(a) selecting at least two of the nodes to receive the same request to process a transaction;

(b) receiving at the at least two nodes the same request to process a transaction;

(c) the processor at each of the at least two nodes executing in the application the same request to process a transaction;

(d) replicating from at least one of the at least two nodes to one or more other nodes in the system the steps and operations of the transactions up until the transaction END step;

(e) identifying in the at least one check integrity module whether the transaction should be checked for integrity;

(f) performing the following steps when the transaction is identified as a transaction that should be checked for integrity;

(i) comparing in the processor at the one or more other nodes in the system the replicated steps and operations of the transactions that were received from each of the at least two nodes, and

(ii) performing a transaction END step for the replicated transaction in the application executing in the processor at the one or more other nodes in the system by;

(A) executing a COMMIT when the result of the comparison in step (f)(i) indicates that the replicated steps and operations of the replicated transactions match each other, and

(B) executing an ABORT when the result of the comparison in step (f)(i) indicates that the replicated steps and operations of the replicated transactions do not match each other; and

(g) executing a COMMIT as the transaction END step when the transaction is not identified as a transaction that should be checked for integrity.

2. The method of claim 1 wherein step (a) is performed by a transaction distributor.

3. The method of claim 1 wherein step (d) further comprises replicating from each of the at least two nodes to one or more other nodes in the system the steps and operations of the transactions up until the transaction END step.

4. The method of claim 1 wherein step (d) further comprises replicating from only one of the nodes to one or more other nodes in the system the steps and operations of the transactions up until the transaction END step when the transaction is not identified as a transaction that should be checked for integrity.

5. The method of claim 1 wherein in step (c) the processor at each of the at least two nodes further computes indicia of the outcome of the processing of the same request, the method further comprising:

(h) the transaction distributor, or at least one of the plurality of nodes, comparing the computed indicia to validate the transaction processed at the at least two nodes.

6. The method of claim 1 wherein the replication in step (d) occurs via an intermediary node.

7. The method of claim 1 wherein the check integrity module executes in the transaction distributor.

8. The method of claim 1 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on a user request or user ID.

9. The method of claim 1 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on certain tables or files that are updated in the transaction.

10. The method of claim 1 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on a monetary value of the transaction exceeding a threshold.

11. The method of claim 1 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on operating conditions of the system.

12. A method of performing transaction processing in a system, the system including a transaction distributor, at least one check integrity module, and a plurality of nodes, each node in the system including (i) a processor, (ii) an application executing in the processor, and (iii) an instance of a database used by the application, each node executing transactions, each transaction including a BEGIN step, one or more data manipulation language (DML) or data definition language (DDL) operations, and a transaction END step which is either a COMMIT or an ABORT, the method comprising:

(a) selecting at least two of the nodes to receive the same request to process a transaction;

(b) receiving at the at least two nodes the same request to process a transaction;

(c) the processor at each of the at least two nodes executing in the application the same request to process a transaction;

(d) replicating from one of the at least two nodes to one or more other nodes in the system the steps and operations of the transactions up until the transaction END step;

(e) identifying in the at least one check integrity module whether the transaction should be checked for integrity;

(f) performing the following steps when the transaction is identified as a transaction that should be checked for integrity;

(i) the processor at at least one of the at least two nodes computing indicia of the outcome of the processing of the same request;

(ii) replicating the computed indicia in step (f)(i) to one or more other nodes in the system;

(iii) locally computing indicia in the processor at the one or more other nodes in the system from the steps and operations of the transactions replicated in step (d);

(iv) comparing in the processor at the one or more other nodes in the system;

(A) the locally computed indicia, and

(B) the replicated computed indicia that was replicated in step (f)(ii); and

(v) performing a transaction END step for the transaction in the application executing in the processor at the one or more other nodes in the system by;

(A) executing a COMMIT when the result of the comparison in step (f)(iv) indicates that the locally computed indicia matches the replicated computed indicia, and

(B) executing an ABORT when the result of the comparison in step (f)(iv) indicates that the locally computed indicia does not match the replicated computed indicia; and

(g) executing a COMMIT as the transaction END step when the transaction is not identified as a transaction that should be checked for integrity.

13. The method of claim 12 wherein the replication in step (d) occurs via an intermediary node.

14. The method of claim 12 wherein the replication in step (f)(ii) occurs via an intermediary node.

15. The method of claim 12 wherein step (a) is performed by a transaction distributor.

16. The method of claim 12 wherein the check integrity module executes in the transaction distributor.

17. The method of claim 12 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on a user request or user ID.

18. The method of claim 12 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on certain tables or files that are updated in the transaction.

19. The method of claim 12 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on a monetary value of the transaction exceeding a threshold.

20. The method of claim 12 wherein the identification of whether the transaction should be checked for integrity in step (e) is based on operating conditions of the system.