Assertion-Locking Memory-Objects for Database Concurrency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database systems face performance issues due to the use of coarse table locks for serializing assertion-triggering transactions, which unnecessarily block non-assertion-triggering transactions and reduce concurrency.
Innovation Solution
The implementation of Assertion-Locking Memory-Objects (ALMOs) allows for finer-grained locking, enabling high concurrency while ensuring correct SQL assertion validation by locking special-purpose resources instead of rows or tables, and using Guard Queries and UQ-JoinGraphs to determine necessary locks for assertion-triggering transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If coarse table locks are used to serialize assertion-triggering transactions, then SQL assertion validation correctness is ensured, but concurrency is reduced and non-assertion-triggering transactions are unnecessarily blocked
Solution Approach 1:
The patent segments the locking mechanism from table-level to assertion-level. Instead of locking entire tables when any assertion might be triggered, the system creates separate lock objects for each SQL assertion. This allows fine-grained control where only transactions affecting specific assertions contend for those assertion locks, while other transactions can proceed concurrently with different assertions or non-assertion-triggering operations.
Solution Approach 2:
The patent introduces assertion lock objects as intermediary resources between transactions and table data. These lock objects serve as mediators that serialize only the critical section of assertion validation for specific assertions, rather than serializing all access to the underlying tables. The lock objects act as a buffer that allows concurrent access patterns to coexist while maintaining assertion validation correctness.
2Reliability
If table locks are acquired for assertion validation, then assertion-triggering transactions are properly serialized, but non-assertion-triggering transactions are blocked unnecessarily
Solution Approach 1:
The patent segments the serialization scope from table-wide to assertion-specific. Each SQL assertion has its own lock object, so only transactions that trigger that specific assertion need to acquire and wait for its lock. Non-assertion-triggering transactions or transactions triggering different assertions can proceed without waiting, eliminating unnecessary blocking and waiting time.
Solution Approach 2:
The patent applies local quality by making locking behavior specific to each assertion's requirements. Different assertions can have different locking characteristics based on their selectivity and impact. The system dynamically determines which lock objects to acquire based on whether a transaction is assertion-triggering, applying serialization only where needed rather than uniformly across all transactions.
Data Source
AI summary
Techniques are disclosed for serializing assertion-triggering transactions by locking special purpose resources (i.e. other than rows or tables), which enables a high level of concurrency for these transactions while at the same time ensuring correctness of the SQL assertion validation code. The techniques involve creating objects referred to therein as “Assertion-Locking Memory-Objects” or “ALMOs”. The database server causes each assertion-triggering transaction to obtain locks on one or more ALMOs prior to determining whether the changes made by assertion-triggering transaction violates the assertion. Because locks on the ALMOs are finer than the table locks, fewer transactions are blocked by ALMO locks.