Transaction support for distributed data

• US 8,868,514 B2
• Filed: 01/07/2011
• Issued: 10/21/2014
• Est. Priority Date: 01/07/2011
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Lomet, David, Mokbel, Mohamed, Levandoski, Justin, Zhao, Keliang
• Primary Examiner(s): Robinson, Greta
• Assistant Examiner(s): Weinrich, Brian E.
• Application Number:
  US12/986,962
• Publication Number:
  US 20120179645A1
• Time in Patent Office: 1,383 Days
• Field of Search: 707/682, 707/607, 707/648
• US Class Current: 707/682
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Abstract

A distributed system with transaction support may have a transaction component and one or more data components. The transaction component may manage a transaction using a log sequence number for each operation, and then transmit operations to one or more data components with log sequence numbers. The data components may perform the data operations in an idempotent manner and return a reply. The transaction component may then write the operation, its log sequence number, and information from the reply message to its log. The transaction component is able to commit a transaction, as well as retry or undo portions of a transaction, by using the information stored on its log. This may be possible even when a single transaction uses multiple data components, which may be located on different devices or manage separate and independent data sources.

Claims

1. A method comprising:

receiving a transaction from a client device, the transaction including a sequence of data operations for a plurality of data components;

adding one or more data operations to the transaction;

for each of the data operations;

identifying one or more records associated with the data operation;

locking the one or more identified records;

identifying one of the plurality of data components to process the data operation;

transmitting the data operation to the identified data component;

receiving a reply from the identified data component, the reply including information used to undo or redo the data operation; and

writing the data operation and the information from the reply to a log;

after receiving replies for each data operation, determining whether each data operation has been made stable;

transmitting a command to each of the plurality of data components to indicate that the data operations are permitted to be written to stable storage when it has been determined that each of the data operations have been made stable;

writing a transaction commit record to the log;

releasing any locks on the identified records;

committing the transaction after each of the data operations of the transaction and the commit record have been determined to be stable; and

transmitting a committed transaction reply to the client device to indicate that the transaction has been committed.

2. The method of claim 1, further comprising establishing an authenticated session with the client device prior to receiving the transaction.

3. The method of claim 1, wherein at least one of the data operations is a write operation.

4. The method of claim 1, further comprising detecting a failure with one of the data operations and causing the identified data component to undo at least one of the previous data operations.

5. The method of claim 1, further comprising determining that one of the data operations may not have been completed and resending that data operation to the identified data component.

6. The method of claim 5, wherein determining that one of the data operations may not have been completed comprises failing to receive a reply from the identified data component.

7. The method of claim 5, wherein the resent data operation already completed prior to the resending and the identified data component performed the data operation in an idempotent manner.

8. The method of claim 1, wherein at least one of the data operations is an add operation.

9. A system comprising:

at least one data component comprising;

a processor;

a storage system; and

a data component manager that;

receives data operation requests comprising data operations;

processes the data operation requests; and

returns a reply;

at least one transaction component comprising;

a processor; and

a transaction component manager that;

receives a transaction from a client device, the transaction including a sequence of data operations;

adds one or more data operations to the transaction;

for each of the data operations;

identifies one or more records associated with the data operation;

locks the one or more identified records;

transmits a data operation request comprising the data operation to the data component;

receives a reply from the data component, the reply including information used to undo or redo the data operation; and

writes the data operation and the information from the reply to a log;

after receiving replies for each data operation, determines whether each data operation has been made stable;

transmits a command to the data component to indicate that the data operations are permitted to be written to stable storage when it has been determined that each of the data operations have been made stable;

writes a transaction commit record to the log;

releases any locks on the identified records;

commits the transaction after the data operations of the transaction and the commit record have been determined to be stable; and

transmits a committed transaction reply to the client device to indicate that the transaction has been committed.

10. The system of claim 9, wherein the transaction component manager further detects a failure with one of the data operation requests and causes the data component to undo at least one of the previous data operation requests.

11. The system of claim 9, wherein the transaction component manager fails to receive a reply for one of the data operation requests and resends that data operation request to the data component.

12. The system of claim 11, wherein the data operation corresponding to the resent data operation request already completed before the request is resent and the data component performed the data operation in an idempotent manner.

13. The system of claim 9, further comprising a session manager to establish an authenticated session with the client device prior to receiving the transaction from the client device.

14. The system of claim 9, wherein at least one of the data operations is a write operation.

15. A system comprising:

a transaction component comprising;

a processor;

a session manager configured to operate on the processor, the session manager that establishes an authenticated session with a client device; and

a transaction component manager that;

receives from the client device a transaction having a plurality of data operations, each data operation to be performed on one of a plurality of data components;

adds one or more data operations to the transaction;

for each of the data operations;

identifies one or more records associated with the data operation;

locks the one or more identified records;

identifies one of the plurality of data components to process the data operation;

transmits the data operation to the identified data component;

receives a reply from the identified data component, the reply including information used to undo or redo the data operation; and

writes the data operation and the information from the reply to a log;

after receiving replies for each data operation, determines whether each data operation has been made stable;

transmits a command to the plurality of data components to indicate that the data operations are permitted to be written to stable storage when it has been determined that each of the data operations have been made stable;

writes a transaction commit record to the log;

releases any locks on the identified records;

commits the transaction after the data operations of the transaction and the

commit record have been determined to be stable; and

transmits a committed transaction reply to the client device to indicate that the transaction has been committed.

16. The system of claim 15, wherein the transaction component manager further detects a failure with one of the data operation requests and causes the identified data component to undo at least one of the previous data operation requests.

17. The system of claim 15, wherein the transaction component manager fails to receive a reply for one of the data operation requests and resends that data operation request to the identified data component.

18. The system of claim 17, wherein the data operation corresponding to the resent data operation request already completed before the request is resent and the identified data component performed the data operation in an idempotent manner.

19. The system of claim 15, wherein at least one of the data operations is a write operation.

20. The system of claim 15, wherein at least one of the data operations is a delete operation.