Lock Service Layer for Distributed Database Transaction Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Distributed databases face challenges in supporting transactional access due to asynchronous responses, leading to errors such as duplicate transactions and data inconsistencies, as data operations across nodes can be executed out of order, causing issues like lost modifications, dirty reads, non-repeatable reads, and phantom reads.
Innovation Solution
A distributed database system with a lock service layer that partitions data and manages lock requests, ensuring that target data is locked only for the current transaction, blocking other transactions and operations from accessing it, thereby implementing atomicity and isolation through queue management and lock status monitoring.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If asynchronous database operations are performed in a distributed database, then access speed and parallelism are improved, but data consistency and transaction reliability deteriorate
Solution Approach 1:
The patent applies preliminary action by acquiring locks on target data before executing database operations. The lock acquisition happens in advance (before the actual data modification), ensuring that no other transaction can access or modify the same data during the critical section. This preliminary locking mechanism guarantees data consistency while allowing multiple transactions to proceed in parallel on different data, thus maintaining both reliability and productivity.
2Reliability
If lock requests are blocked and queued, then transaction isolation is improved, but processing time and system response delay increase
Solution Approach 1:
The patent applies local quality by implementing fine-grained locking at the data level rather than using coarse-grained table or database locks. Each lock request targets specific target data (rows or columns), allowing different transactions to access different portions of the database simultaneously. This localized approach minimizes blocking and queuing delays while maintaining strong isolation guarantees for each transaction's specific data scope.
3Adaptability or versatility
If data is partitioned and distributed across multiple nodes, then system scalability and storage capacity are improved, but transaction coordination complexity and communication overhead increase
Solution Approach 1:
The patent applies segmentation by dividing the database into multiple partitions distributed across different nodes, with each partition independently manageable. The lock service layer segments lock requests into local lock acquisitions on each node, avoiding the need for centralized lock coordination across the entire distributed system. This segmentation reduces coordination complexity while maintaining scalability, as each node can process lock requests independently for its local partitions.
Data Source
AI summary
A distributed database system may include storage layer. The storage layer may partition data and store the partitioned data in a distributed database. The system may further include access layer. The access layer may receive a transaction, identify target data corresponding to the transaction, and generate a lock request to lock the target data included in the partitioned data. The system may further include lock service layer. The lock service layer may identify, based on the lock request, a lock status for the target data according to a lock record for the target data. The lock service layer may lock, in response to the lock status being in an unlocked state, the target data. The lock service layer may block, in response to the lock status being in a locked state, the lock request and store the lock request in a queue.