External Transaction Engine for Non-Transactional Data Store Consistency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database systems without transaction capabilities face challenges in maintaining data consistency when performing updates across hierarchies of data objects, leading to potential incomplete or inconsistent views for users, as they lack the atomicity of transactions.
Innovation Solution
Implementing a transaction engine external to the non-transactional data store that manages transaction descriptions for hierarchies of data objects, allowing for atomic updates by storing changes in a parent object and applying them when new transactions are submitted, ensuring consistent views even before all child objects are updated.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If transaction capabilities are implemented in a data store, then data consistency is improved, but device complexity and performance are worsened
Solution Approach 1:
The patent extracts the transaction management functionality from the data store itself and places it in an external transaction manager. The data store continues to operate as a simple non-transactional store, while the transaction manager handles transaction descriptions, coordination, and consistency guarantees externally.
Solution Approach 2:
The patent introduces a transaction manager as an intermediary layer between the client applications and the data store. This mediator handles transaction coordination, stores transaction descriptions, and manages the atomicity and consistency of operations without requiring the underlying data store to have native transaction capabilities.
2Reliability
If transaction capabilities are implemented in a data store, then data consistency is improved, but performance is worsened
Solution Approach 1:
By extracting transaction management from the data store, the patent allows the data store to operate at its full native performance capacity without the overhead of transaction processing, while still providing transactional semantics through the external transaction manager.
Solution Approach 2:
The patent stores transaction descriptions in advance in the data store before actual data modifications occur. This preliminary action allows the transaction manager to coordinate changes efficiently and provides a blueprint for maintaining consistency without requiring the data store to process complex transaction logic in real-time.
3Productivity
If updates are applied to child objects without transactions, then performance is improved, but data consistency is worsened
Solution Approach 1:
The patent implements a feedback mechanism where the transaction manager monitors the application of updates to child objects and uses the stored transaction descriptions to verify and restore consistency. When inconsistencies are detected, the system can rollback or correct the changes based on the transaction description.
Solution Approach 2:
By storing the transaction description (which includes the intended changes and dependencies) before applying updates to child objects, the system creates a recovery mechanism that ensures consistency can be restored if needed, without preventing the performance benefits of non-transactional updates.
Data Source
AI summary
A transaction directed to a hierarchy of data objects stored in a non-transactional data store may be executed. The transaction may be received and description of the transaction stored in a parent data object of the hierarchy. Upon storing the description of the transaction, the transaction may be acknowledged as committed. Access requests for the hierarchy of data objects may be serviced by accessing the description of the transaction and applying to child data objects in the hierarchy returned for servicing a query directed to the hierarchy. A new transaction that is received may initiate application of the transaction according to the description in the parent data object with respect to child data objects.


