Transaction Controller for Stateless UI-Database Draft Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current UI development toolkits lack techniques for orchestrating and managing transactions in stateless communication environments, leading to redundant code and inconsistent behaviors across applications and implementations, as they do not maintain session information.
Innovation Solution
A transaction controller with APIs that manages draft-enabled web applications by maintaining a secondary persistence of application data, allowing developers to create, edit, and delete drafts without affecting active business data, and ensures atomicity and transactional consistency through batch requests and validation processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If manual coding is used to control interactions between UI and database in stateless environment, then developers can implement application logic, but redundant code and inconsistent behaviors occur across different applications
Solution Approach 1:
The patent introduces a transaction controller as an intermediary component between the user interface and the database. This controller maintains session state information and manages transactions across multiple stateless HTTP requests, eliminating the need for manual coding of transaction logic in each application. The transaction controller serves as a mediator that ensures consistent behavior across different applications while reducing code redundancy through centralized transaction management.
Solution Approach 2:
The transaction controller is designed as a universal component that can be reused across multiple web applications. It provides multi-functional capabilities including session state management, transaction orchestration, and coordination of UI-database interactions. This universal component eliminates the need for each application to implement its own transaction management logic, thereby reducing code redundancy and ensuring consistent behavior across different applications.
2Productivity
If stateless communication protocol is used between UI and database, then network communication is simplified, but session information cannot be retained between interactions
Solution Approach 1:
The transaction controller acts as an intermediary that maintains session state information on the server side while the communication protocol remains stateless. It stores session information in memory or storage and retrieves it across multiple HTTP requests, effectively bridging the gap between stateless communication and stateful application requirements without changing the underlying communication protocol.
Solution Approach 2:
The patent shifts the state management from the communication protocol dimension to the application layer dimension. Instead of making the HTTP protocol stateful, the transaction controller maintains session state at the application layer, separating the concerns of communication efficiency (maintained at protocol level) from session information retention (handled at application level).
3Reliability
If developers manually manage transactions without orchestration tools, then implementation flexibility is maintained, but transactional integrity and atomicity cannot be ensured
Solution Approach 1:
The transaction controller serves as a mediator that automatically ensures transactional integrity and atomicity by managing transactions centrally. It coordinates read and write operations, implements proper locking mechanisms, and ensures that transactions are committed or rolled back atomically. This eliminates the need for developers to manually implement complex transaction management logic while maintaining implementation flexibility through the provided API.
Solution Approach 2:
The transaction controller provides self-service capabilities by automatically handling transaction coordination, validation, and error recovery. It monitors transaction states, manages resource allocation, and ensures atomicity without requiring manual intervention. This automated self-service approach ensures transactional integrity while reducing the complexity of transaction management for developers.
4Stability of the object's composition
If drafts are stored in the same database as active business data, then data consistency is maintained, but application downtimes occur when modifying active data
Solution Approach 1:
The patent segments the database storage into separate tables or partitions for draft data and active business data. Draft data is stored in a separate draft table that is isolated from the active business data table. This segmentation allows drafts to be created, edited, and deleted without locking or affecting access to active business data, thereby maintaining application availability while ensuring data consistency through controlled transition mechanisms.
Solution Approach 2:
The system performs preliminary actions by creating draft versions of business data before making changes to active data. Users can work with draft data in parallel without affecting active data, and only after draft validation and approval are changes committed to the active business data. This preliminary action approach maintains application availability by allowing concurrent access while ensuring data consistency through the draft-to-active transition process.
Data Source
AI summary
Various embodiments of systems and methods to control interactions between an application user interface and a database are described herein. In one aspect, a secondary persistency of application data is generated based on a primary persistency of the application data in a database. A request to modify a value of a field of the application data in the secondary persistency is received from the application user interface. The field of the application data in the secondary persistency is updated in response to the received request for modification. A determination is made that the received request for modification influences other fields of the application data according to a set of rules. The other fields of the application data are updated based on the received request. The application data in the secondary persistency is then transitioned to the primary persistency upon request.