Transactional Database System Using Private Data Copies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current distributed data storage systems lack transactional support, making it difficult to use them for sophisticated data applications, as they do not provide atomic access to multiple data objects or ensure all-or-nothing updates.
Innovation Solution
A transactional database system that implements transactions over data objects stored in a strongly consistent object storage system by making a private copy of data objects used by the transaction, reducing the need for mutually exclusive locks and allowing easy portability across different data storage systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If strongly consistent writes are implemented in distributed storage systems, then write predictability and performance are improved, but transactional access capability deteriorates
Solution Approach 1:
The patent introduces a transaction coordinator as an intermediary component that manages transactional operations across the distributed storage system. This coordinator mediates between clients and storage nodes, enabling transactional semantics (atomicity, consistency, isolation, durability) without requiring changes to the underlying strongly consistent storage infrastructure. The coordinator orchestrates lock acquisition, transaction logging, and commit/rollback operations across multiple storage nodes.
Solution Approach 2:
The patent segments transactional functionality into separate components: transaction coordinators that manage transaction logic, storage nodes that handle data operations, and clients that initiate transactions. This segmentation allows the strongly consistent storage system to maintain its write performance while the transaction coordinator layer provides transactional capabilities. Each segment operates independently with well-defined interfaces.
2Reliability
If transactional access is implemented over strongly consistent storage, then atomic access to multiple data objects is improved, but lock usage increases
Solution Approach 1:
The patent implements optimistic concurrency control where the transaction coordinator creates copies of transaction logs and lock state information. Instead of maintaining complex distributed lock tables, the system uses copy-based approaches for transaction validation and conflict detection. This reduces the complexity of lock management while ensuring atomic access through cryptographic verification of data consistency.
Solution Approach 2:
The patent replaces traditional mechanical distributed locking mechanisms with software-based transaction coordination and validation. Instead of relying on hardware locks or complex inter-node communication protocols for locking, the system uses software transaction identifiers, logging, and validation logic to ensure atomicity. This substitution reduces lock-related complexity and improves scalability.
3Adaptability or versatility
If client-developed transactional solutions are used, then transactional functionality is achieved, but portability across different storage systems deteriorates
Solution Approach 1:
The patent creates a universal transaction coordinator architecture that can operate with multiple types of underlying storage systems (strongly consistent object storage, distributed file systems, cloud storage services). The coordinator uses standardized interfaces and protocols that are storage-agnostic, allowing the same transactional layer to work across different storage backends. This multi-functionality enables portability of transactional applications without requiring client-specific implementations for each storage system.
Data Source
AI summary
Embodiments of a transactional database system are described to implement transaction processing over database objects stored in a strongly consistent object storage system. When a transaction is initiated, the system makes a private copy of data objects that are used by the transaction. Reads and writes of the transaction will be performed on the private copy. When the transaction is to be committed, the system verifies that the committed state of the data objects has not changed outside the transaction, and updates metadata object(s) in the data storage system to point to the private copy as the currently committed state of the data objects. If the committed state of any data objects has changed during the transaction, the private copy is abandoned and the transaction is rolled back and/or retried.