Object-Level Database Transaction Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database transaction systems face inefficiencies due to strict adherence to atomicity, which limits application flexibility and can lead to wait times for all changes to be approved, even if some changes are not dependent on others.
Innovation Solution
A page transaction model that allows for customizable rules and relationship definitions to manage changes submitted through user interface pages, enabling individual database transactions to be processed asynchronously and independently, with the option to roll back only failed transactions, while allowing other changes to be committed.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If strict atomicity is enforced for all database transactions, then data consistency and protection against interference are improved, but application flexibility and processing efficiency deteriorate due to requiring all changes to be approved before any can be committed
Solution Approach 1:
The patent segments a single atomic transaction into multiple independent object-level transactions. Each object or group of related objects can be processed separately, allowing partial commits without waiting for all changes to be approved. This maintains data consistency at the object level while improving overall processing efficiency.
Solution Approach 2:
The patent enables partial action by allowing individual objects or groups of objects to be committed independently even when other objects in the same submission are still pending approval. This partial commit capability improves productivity while maintaining reliability through selective atomicity.
2Reliability
If all changes must be approved before any are committed, then data consistency is maintained, but wait time increases and application flexibility decreases
Solution Approach 1:
By segmenting the transaction into object-level units, the system can approve and commit independent objects as soon as they are ready, rather than waiting for all objects to be approved. This significantly reduces wait time while maintaining data consistency through controlled atomicity at the object level.
Solution Approach 2:
The patent introduces dynamic transaction processing where the degree of atomicity can be adjusted based on object dependencies. Related objects can be grouped together for atomic processing, while independent objects can be processed separately, creating a dynamic approach that optimizes both reliability and time efficiency.
3Reliability
If atomicity is applied to the entire page submission, then data integrity is protected, but adaptability to different approval scenarios is reduced
Solution Approach 1:
The patent segments the page submission into multiple object-level transactions, each with its own atomicity control. This allows different approval scenarios to be handled differently - some objects can require strict atomic approval while others can be processed independently, greatly enhancing adaptability to various business scenarios.
Solution Approach 2:
The patent applies local quality by enabling different atomicity levels for different objects within the same page submission. Each object or object group can have its own atomicity settings based on its specific requirements, allowing flexible adaptation to diverse approval scenarios while maintaining data integrity where needed.
Data Source
AI summary
Techniques are described handling database transaction in a manner that is efficient and flexible. In some embodiments, a system receives, through a page of a user interface, a first request to change at least a first data object. The system generates, based on the first request, a first atomic transaction to modify the first data object in a database. Before the first atomic database transaction has committed to the database, the system receives, through the page of the user interface, a second request to change at least a second data object. The system generates, based on the second request, a second atomic transaction to modify the second object in the database. The system may execute the second atomic transaction independently of the first atomic transaction.