Minimizing Commit Latency of Transactions in Geo-Replicated Data Stores

F Nawab, V Arora, D Agrawal, A El Abbadi 2015

• data centers keep a log of all transactions (prepared to be committed and those that were committed already)
• this log is exchanged between the data centers every now and then
• clients create a list of read/write transactions and then commit them
• data center before committing a transaction marks it as ‘prepared to be committed in the log
• log is shared with all other data centers
• after some time data center checks if there are conflicting transactions (prepared to be committed or the ones committed already) in the latest transactions log [Prepared Transactions Pool - PTP local and remote)
• if there is a conflict - discard the transaction, if no - commit and add it the log
• remote transactions are either preparing or finished (committed or aborted)

Liveliness (what should we do if something goes down without telling us about its pending transactions)

• Data center can check whether his transactions log has been received by n other data centers by checking the latest log it receives from them
• the idea is to wait for that before committing
• if data center A doesn’t receive the log from data center B (that got disconnected), it tries to contact data center C that keeps the local copy of B’s transaction log. Now even if B goes up it will not be able to commit his transactions without checking the log at C.
• data center C will only acknowledge commit from B if it was notified about it within the grace time - a special timeout

Evaluation:

with increase of the liveliness level (number of failing data centers) the throughput dramatically decreases up to 37% lower than without any protection

small deviation of the clocks is not really a problem