Lock-Free Reservation Journals for High-Contention Database Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database systems face performance issues due to long-term resource locking during sagas, leading to reduced concurrency and increased response times, especially when dealing with high-contention scenarios involving numeric and aggregate data updates.
Innovation Solution
Implement Lock-Free Reservation techniques that allow transactions to defer row lock acquisition for updates on numeric columns, using reservation journals to track pending updates and ensure constraint satisfaction at commit time, thereby enhancing concurrency without compromising semantic correctness.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If long-term resource locking is used during sagas to ensure data consistency, then reliability is improved, but concurrency is reduced and response time increases
Solution Approach 1:
The patent segments the locking mechanism into two distinct phases: optimistic validation phase (no locking, high concurrency) and commit phase (locking, consistency guarantee). This segmentation allows transactions to proceed without locks during the main execution, improving concurrency, while still ensuring data consistency at the critical commit point.
Solution Approach 2:
The patent performs preliminary validation of constraints and conditions before acquiring locks. By validating data integrity requirements in advance (during the optimistic phase), the system reduces the duration of lock holding, thereby improving concurrency while maintaining reliability through pre-validated consistent states.
2Reliability
If row lock acquisition is performed early to ensure data consistency, then reliability is improved, but response time increases due to blocking
Solution Approach 1:
The patent performs preliminary constraint validation and optimistic checks before acquiring row locks. This preliminary action ensures that when locks are finally acquired, the actual data manipulation can proceed immediately without blocking, as the validation work has already been completed in the lock-free optimistic phase.
Solution Approach 2:
The patent allows transactions to skip the locking phase entirely during execution, rushing through the main transaction logic without blocking. Locks are only acquired at the critical commit moment, minimizing the time spent in locked state and reducing response time while maintaining consistency guarantees.
3Reliability
If conventional locking mechanisms are used for numeric and aggregate data updates, then data integrity is maintained, but transaction throughput decreases under high contention
Solution Approach 1:
The patent segments the update process into optimistic validation (lock-free, high throughput) and committed update (locked, integrity-guaranteed) phases. This segmentation allows multiple transactions to validate and prepare updates concurrently without blocking, dramatically improving throughput under high contention while maintaining data integrity through the final locked commit phase.
Solution Approach 2:
The patent implements optimistic validation where transactions self-validate constraints and conditions without requiring external locking mechanisms. This self-service approach allows concurrent transactions to independently verify data integrity requirements, improving throughput while the final commit phase ensures overall data integrity through coordinated locking.
Data Source
AI summary
A Lock-Free Reservation mechanism is provided. When a transaction issues an update that affects a value in a “reservable column” of a row, the database server does not immediately obtain a lock that covers the row. Instead, the database server adds a reservation to a reservation journal. At the time the transaction commits, a lock is obtained and the requested update is made. In one implementation, before adding the reservation to the reservation journal, the database server determines whether making the update would violate any constraints involving the reservable column. In one implementation, the constraint check not only takes into account the current value of the data item that is being updated and the amount of the update, but also pre-existing reservations in the reservation journal that affect the same data item.