Reducing commit wait in a distributed multiversion database by reading the clock earlier
In a distributed system where a client's call to commit a transaction occurs outside the transaction's lock-hold interval, computation of timestamp information for the transaction is moved to a client library, while ensuring that no conflicting reads or writes are performed between a time of the computation and acquiring all locks for the transaction. The transaction is committed in phases, with each phase being initiated by the client library. Timestamp information is added to the locks to ensure that timestamps are generated during lock-hold intervals. An increased number of network messages is thereby overlapped with a commit wait period in which a write in a distributed database is delayed in time to ensure concurrency in the database.
1. A method, comprising:
receiving, at a server in a distributed system from a client, a transaction to be committed to the distributed system;
identifying, by the server, a tentative timestamp for the transaction, wherein the tentative timestamp is computed using a value for a current time plus a variable corresponding to bounds of uncertainty of clocks in the distributed system, the clocks including at least a client clock at the client and a server clock at the server;
receiving, by the server, a commit initialization for the transaction from the client outside of a lock-hold interval for the transaction; and
executing the transaction based on the tentative timestamp.
2. The method of claim 1 , wherein the transaction comprises a write, further comprising deferring the write until the client initiates the commit.
3. The method of claim 1 , further comprising deferring acquisition of locks until the client initiates the commit.
4. The method of claim 1 , further comprising checking for conflicting transactions.
5. The method of claim 4 , wherein checking for conflicting transactions comprises checking whether any other transaction holds a lock during a time period that includes the tentative timestamp.
6. The method of claim 4 , further comprising:
detecting a conflicting transaction; and
determining whether the conflicting transaction has higher priority.
7. The method of claim 6 , further comprising forcing the conflicting transaction to give up its lock and start over when the conflicting transaction has lower priority.
8. The method of claim 6 , further comprising updating the tentative timestamp when the conflicting transaction has higher priority.
9. The method of claim 8 , wherein updating the tentative timestamp comprises moving it to a later time to avoid the conflict.
10. The method of claim 1 , further comprising acquiring locks in response to receiving the commit initialization.
11. A system, comprising:
one or more memories;
a server in communication with the one or more memories in a distributed system, the server configured to:
receive, from a client, a transaction to be committed to the distributed system;
identify a tentative timestamp for the transaction, wherein the tentative timestamp is computed using a value for a current time plus a variable corresponding to bounds of uncertainty of clocks in the distributed system, the clocks including at least a client clock at the client and a server clock at the server;
receive a commit initialization for the transaction from the client outside of a lock-hold interval for the transaction; and
execute the transaction based on the tentative timestamp.
12. The system of claim 11 , wherein the transaction comprises a write, wherein the server is further configured to defer the write until the client initiates the commit.
13. The system of claim 11 , wherein the server is further configured to defer acquisition of locks until the client initiates the commit.
14. The system of claim 11 , wherein the server is further configured to check for conflicting transactions, wherein checking for conflicting transactions comprises checking whether any other transaction holds a lock during a time period that includes the tentative timestamp.
15. The system of claim 14 , wherein the server is further configured to:
detect a conflicting transaction; and
determine whether the conflicting transaction has higher priority.
16. The system of claim 15 , wherein the server is further configured to force the conflicting transaction to give up its lock and start over when the conflicting transaction has lower priority.
17. The system of claim 15 , wherein the server is further configured to update the tentative timestamp when the conflicting transaction has higher priority.
18. The system of claim 17 , wherein updating the tentative timestamp comprises moving it to a later time to avoid the conflict.
19. The system of claim 11 , wherein the server is further configured to acquire locks in response to receiving the commit initialization.
20. A computer-readable medium storing instructions executable by one or more processors for performing a method, comprising:
receiving, at a server in a distributed system from a client, a transaction to be committed to the distributed system;
identifying, by the server, a tentative timestamp for the transaction, wherein the tentative timestamp is computed using a value for a current time plus a variable corresponding to bounds of uncertainty of clocks in the distributed system, the clocks including at least a client clock at the client and a server clock at the server;
receiving, by the server, a commit initialization for the transaction from the client outside of a lock-hold interval for the transaction; and
executing the transaction based on the tentative timestamp.