Faulted Database Transaction Recovery Through Automatic Resubmission
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems require end-users to manually reconstruct and resubmit database transaction records upon failure, leading to inefficiency and resource strain due to duplicate efforts and notifications, especially when failures are caused by validation errors.
Innovation Solution
A system that uses a mapping table to generate a new transaction record from an original transaction's invocation context, allowing automatic resubmission through the same interface, transparent to the end-user, and enabling administrative accounts to correct validation errors without user intervention.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the system terminates the transaction record and requires the submitting system to reinitiate the process, then the validation failure is clearly communicated, but the user effort and system resources are wasted due to manual reconstruction and resubmission
Solution Approach 1:
The system performs preliminary actions by storing the transaction record and invocation context in the transaction data store before termination. This allows the transaction to be automatically reconstructed and resubmitted without requiring user intervention, thus preventing the loss of time and effort while maintaining validation accuracy.
Solution Approach 2:
The system creates a copy of the original transaction record by retrieving it from the transaction data store and reconstructing it with the stored invocation context. This copy can be automatically resubmitted, eliminating the need for users to manually recreate the transaction while ensuring validation rules are properly applied.
2Reliability
If the system requires manual reconstruction of transaction records, then validation errors can be addressed, but system productivity decreases due to duplicate processing efforts
Solution Approach 1:
The system enables self-service by automatically retrieving, reconstructing, and resubmitting failed transaction records without requiring user intervention. The monitor process or administrative account can initiate this automatic resubmission, allowing the system to correct validation errors independently and maintain high productivity.
Solution Approach 2:
The system implements feedback by monitoring validation failures and automatically triggering the resubmission process. The notification sent to the monitor process or administrative account provides feedback about the failure, which then initiates the corrective action of automatic resubmission, improving both reliability and productivity.
3Extent of automation
If the system stores complete transaction objects with invocation context, then automatic resubmission is enabled, but the data storage requirements and system complexity increase
Solution Approach 1:
The system segments the transaction data storage by separating the transaction record from the invocation context. The transaction object is stored in the transaction data store with a reference to the invocation context, which is also stored separately. This segmentation reduces redundancy and simplifies the overall data structure while enabling automatic resubmission.
4Loss of information
If the system sends notifications to end-users for every failure, then users are kept informed, but resource strain increases due to duplicate notifications and manual interventions
Solution Approach 1:
The system introduces an intermediary (monitor process or administrative account) that handles failure notifications and resubmission initiation. Instead of directly notifying end-users for every failure, the intermediary monitors failures and manages the automatic resubmission process, reducing the frequency and intensity of notifications to end-users while maintaining system transparency.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Database transaction records that are received for committing data to a database may be associated with one or more validation tasks. When one of the validation tasks fails, the fault is detected and processing of the transaction record is halted. Instead of terminating the transaction record and requiring the submitting system to reinitiate the process, the system may use a mapping table to determine whether an automatic resubmission is possible. A new transaction record may be generated that copies an invocation context from the original transaction record, and portions of the transaction payload may be copied to the new transaction record with changes that ensure the new transaction record will pass the validation tasks. The new transaction record can then be submitted through the same interface that received the original transaction record, and the original transaction record can be removed from a transaction data store.