Lease-Based Lock Service for Multi-Row Transaction Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current large-scale distributed database systems face inefficiencies in multi-row transactions due to the need for persistent lock metadata, which increases latency and requires additional resources for scaling, compromising performance in online transaction processing tasks.
Innovation Solution
A lightweight in-memory lease-based lock-service is implemented, allowing for ACID-compliant multi-row transactions without persisting lock metadata to non-volatile storage, and is tolerant to lock service failures, ensuring snapshot isolation and reducing latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If lock metadata is persisted to non-volatile storage, then reliability of transaction processing is improved, but latency increases and device complexity increases
Solution Approach 1:
The patent extracts the persistence requirement from lock metadata by introducing a separate volatile memory structure (lease table) that does not require durability. This allows the lock service to operate without persisting lock state, eliminating the latency penalty of flush operations while maintaining transaction reliability through the lease-based mechanism.
Solution Approach 2:
The patent uses a volatile memory structure (lease table) that can be lost on system crash but is quickly reproducible. The lease-based locking mechanism accepts that lock state may be lost and uses the lease table's volatility to its advantage, allowing faster operations without persistence overhead.
2Reliability
If lock metadata is persisted to non-volatile storage, then reliability of transaction processing is improved, but device complexity and resource requirements increase
Solution Approach 1:
The patent separates the locking mechanism from the persistence layer by using a volatile lease table instead of persisting lock metadata. This extraction eliminates the need for complex persistence management while maintaining reliability through the lease-based approach that doesn't depend on durable storage.
Solution Approach 2:
The patent replaces complex persistent lock metadata with a simple volatile lease table that can be quickly recreated. This simplification reduces device complexity and resource requirements while maintaining sufficient reliability for transaction processing.
3Reliability
If traditional locking mechanisms are used, then ACID compliance is maintained, but scalability is limited
Solution Approach 1:
The patent replaces traditional mechanical locking mechanisms with a lease-based system that operates on volatile memory. This substitution enables better scalability by eliminating the need for persistent lock metadata while maintaining ACID compliance through the lease mechanism's atomicity guarantees.
Solution Approach 2:
The patent changes the fundamental parameter of lock state storage from persistent to volatile memory. This parameter change enables the system to scale more effectively by removing persistence overhead while maintaining the essential ACID properties through the lease-based atomicity mechanism.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Techniques are provided for more efficient multi-row atomic, consistent, isolated and durable (ACID)-compliant transactions with snapshot isolation semantics (or just "multi-row transactions" for short). In some embodiments, the techniques are implemented in a computing system that includes a client application, a lightweight in-memory lease-based lock service, a multi-row transaction orchestrator, and an underlying database system. The transaction orchestrator implements a read protocol and a write protocol that provides support to the client application for carrying out multi-row transactions against the underlying database system irrespective of whether the database system itself supports multi-row transactions. The transaction orchestrator explicitly maintains transaction-level locks obtained from the lease-based lock service as part of the transaction protocol. Further, the transaction orchestrator is tolerant to lock service failure and unavailability without compromising ACID-compliance and snapshot isolation guarantees to the client application.