Transaction Commit Lock Release Protocol for Distributed Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional atomic commit and distributed consensus protocols in distributed databases result in increased latency for write operations and subsequent transactions due to the need for multiple sequential rounds of distributed consensus, leading to reduced performance.
Innovation Solution
An improved atomic commitment protocol that reduces latency by allowing transactions to reach the atomicity point after only one round of distributed consensus, and an optimized lock release protocol that enables conflicting transactions to proceed after a single round of consensus, thereby decreasing the wait time for acquiring locks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional atomic commit protocol is layered on distributed consensus, then atomic commitment is achieved across multiple ranges, but latency is multiplied due to sequential consensus rounds
Solution Approach 1:
The patent segments the atomic commit protocol into independent phases that can execute in parallel rather than sequentially. Specifically, the prepare phase and commit phase operate independently across different ranges, allowing multiple consensus rounds to overlap rather than wait for each other. This segmentation breaks the latency multiplication effect by enabling concurrent execution of what was previously sequential operations.
Solution Approach 2:
The patent performs preliminary actions by having the coordinator send prepare requests to all ranges simultaneously before any consensus round completes. The prepare phase collects votes from all ranges in parallel, and only after all votes are gathered does the commit phase begin. This preliminary parallel preparation eliminates the need to wait for sequential consensus completion before starting the next phase.
2Stability of the object's composition
If distributed consensus is used for each range, then strong consistency is maintained, but subsequent transactions must wait for lock release after multiple consensus rounds
Solution Approach 1:
The patent enables continuity of useful action by allowing subsequent transactions to acquire locks and proceed with their operations immediately after the commit phase completes, rather than waiting for the full release phase to finish. The lock release notifications are sent asynchronously in the background, but this does not block subsequent transactions. This maintains consistency while eliminating unnecessary waiting time that reduced productivity.
3Reliability
If multiple sequential consensus rounds are required for commit and lock release, then atomicity is guaranteed, but system performance is reduced
Solution Approach 1:
The patent introduces dynamics by making the commit and release phases independent and non-blocking. The coordinator sends commit decisions to all ranges in parallel, and lock release notifications are dispatched asynchronously after the commit phase completes. This dynamic restructuring allows the system to guarantee atomicity through the coordinated phases while significantly improving performance by eliminating sequential waiting. The asynchronous notification mechanism allows the system to maintain reliability guarantees while enabling concurrent transaction processing.
Data Source
AI summary
Systems and methods for executing conflicting read and write transactions based on a lock release protocol are provided. An intent present at a version of a key can be identified by a first transaction. The first transaction can verify whether the intent corresponds to a second transaction having a simple-committed type to observe the intent as a committed value and proceed with execution or to wait on the second transaction to complete execution. Based on the second transaction being a simple-committed type, the first transaction can determine a provisional value included in the intent as a read value or write a new intent to a new version of the key without waiting for the second transaction to explicitly commit.