Optimistic Serializable Snapshot Isolation for Database Concurrency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional concurrency control mechanisms in database systems, such as strict two-phase locking and snapshot isolation, face challenges like high overhead, bottlenecks, and non-serializable executions due to write skew anomalies, particularly under high concurrency and large data volumes, necessitating more efficient and flexible approaches.
Innovation Solution
Implementing snapshot isolation with two timestamps per transaction and version, where a transaction's reads and writes are validated to ensure serializability by checking version validity and detecting phantoms, allowing provisional handling of in-doubt versions and lazy timestamp assignment, which eliminates the need for a lock manager and supports various isolation levels.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If strict two-phase locking is used for concurrency control, then transaction isolation is ensured, but system throughput decreases and lock management overhead increases
Solution Approach 1:
The patent inverts the conventional locking approach by using optimistic concurrency control instead of pessimistic locking. Transactions execute without acquiring locks and are validated at commit time, reversing the traditional sequence of lock acquisition before execution. This eliminates lock management overhead and blocking while maintaining isolation through validation checks on read and write sets.
Solution Approach 2:
The patent extracts the lock manager component from the concurrency control system entirely. By removing locks and the lock manager, the system eliminates the bottleneck that limited throughput under high concurrency. Concurrency control is achieved through multiversioning and validation mechanisms instead of centralized lock management.
2Productivity
If snapshot isolation is used to eliminate blocking, then read-only transactions are not delayed, but write skew anomalies occur that compromise serializability
Solution Approach 1:
The patent implements feedback through validation at commit time. Transactions execute optimistically without blocking, and the system provides feedback by validating that no write skew anomalies have occurred before allowing commit. The validation process checks for conflicts between concurrent transactions' read and write sets, ensuring serializability while maintaining high throughput during execution.
Solution Approach 2:
The patent performs preliminary validation checks during transaction execution by tracking read and write sets. Before commit, the system preliminarily verifies that no write skew anomalies will occur by checking for conflicts with concurrently executing transactions. This preliminary action prevents non-serializable executions while allowing transactions to proceed without blocking during the main execution phase.
3Ease of operation
If conventional snapshot isolation is implemented, then blocking is eliminated, but overhead from lock management and validation increases
Solution Approach 1:
The patent extracts and removes the lock manager from the system architecture. By eliminating locks entirely in favor of multiversioning with version timestamps, the system removes the complex lock management infrastructure while maintaining non-blocking execution. Concurrency control is achieved through simpler validation of version timestamps and transaction sets.
Solution Approach 2:
The patent uses multiversioning where each data item maintains multiple versions with timestamps. Instead of using locks to control access, the system creates copies of data items with different versions, allowing concurrent transactions to read different versions without blocking. This copying mechanism simplifies concurrency control by replacing complex lock management with version-based validation.
Data Source
AI summary
The subject disclosure relates to a concurrency control technique that ensures isolation among concurrently execution transactions optimistically in a multiversion database by applying two optional tests at the end of a read-write transaction: validating the visibility of the read set of the read-write transaction(s) and phantom detection by re-scanning and confirming no new version have appeared in the view. Depending on desired level of isolation, both, one or none of the test are applied. Each version of a data record in an applicable database can be assigned two timestamps indicating the lifetime the version. The value of a version timestamp, though assigned, may be conditional on a transaction committing.