Metadata-Driven Undo Engine for Cross-System Transaction Rollback

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing computing systems outside of database transactions lack robust consistency mechanisms, leading to inconsistencies and errors during business transactions that span multiple systems, making it difficult to implement and maintain undo logic across these systems.

Innovation Solution

A metadata-driven undo system that uses a metadata repository to store operation types and attributes, generating undo entries and instructions through undolets, allowing for consistent rollback of business transactions across multiple systems without requiring hard-coded logic for each system.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If hard-coded undo logic is programmed for each system, then undo functionality can be provided, but device complexity and maintenance difficulty increase significantly

Engineering Contradiction:
Improveundo functionalityVSAvoidcomplexity of undo logic
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a universal undo engine that can handle multiple types of systems and operations through a single standardized interface. The metadata-driven architecture allows the same undo mechanism to work across database systems, web services, LDAP systems, and other computing systems by dynamically generating appropriate undo logic based on metadata descriptions of the operations being performed.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces an undo engine as an intermediary component between the business transaction coordinator and the various computing systems. This undo engine receives metadata about operations, dynamically generates undo logic, and executes rollback operations without requiring hard-coded undo logic in each individual system, thereby reducing overall complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If hard-coded undo logic is implemented for each system, then undo capability is achieved, but labor costs and error rates increase due to frequent code rewrites

Engineering Contradiction:
Improveundo capabilityVSAvoidmaintenance cost
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The patent employs dynamic generation of undo logic based on metadata rather than static hard-coded logic. When a business transaction involves multiple systems, the undo engine dynamically creates the appropriate undo sequences by querying metadata that describes the operations performed, allowing the system to adapt to changing business requirements without manual code rewrites.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The undo engine performs self-service by automatically generating undo logic from metadata without requiring manual programming for each new system or operation type. The metadata repository stores descriptions of operations and their parameters, enabling the undo engine to autonomously construct the necessary rollback logic when needed.

Inventive Principle:
Principle #25Self-service

3Adaptability or versatility

If changes are made to multiple computing systems during a business transaction, then business functionality is enhanced, but system consistency deteriorates when operations fail

Engineering Contradiction:
Improvebusiness transaction capabilityVSAvoidsystem consistency
Core Design Contradiction:
Adaptability or versatilityVSStability of the object's composition

Solution Approach 1:

The patent implements preliminary action by having the undo engine generate and validate undo logic before the business transaction is committed. The system creates a plan for rolling back operations in reverse order, verifying that undo logic exists for each operation before proceeding with the forward transaction. This ensures that if a failure occurs, the pre-prepared undo logic can restore consistency across all affected systems.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent employs feedback mechanisms where the undo engine continuously monitors the state of computing systems during business transactions and validates that operations are reversible. The system uses metadata to track what operations have been performed and verifies that appropriate undo logic can be generated, providing feedback about the consistency state before and during transaction execution.

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If specialized undo logic is written for each computing system, then system-specific requirements are met, but productivity decreases due to complex and frequent code updates

Engineering Contradiction:
Improvesystem-specific functionalityVSAvoiddevelopment efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent segments the undo functionality into separate, independently manageable components: a metadata repository that stores operation descriptions, an undo engine that generates undo logic, and system-specific adapters that provide metadata for each computing system. This segmentation allows each component to be developed and maintained separately, improving productivity while maintaining system-specific functionality through metadata configurations rather than hard-coded logic.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP2774031B1Oracle rewind: metadata-driven undo
Publication Date: 2016.08.17 ORACLE INT CORP
  • EP2774031B1 patent drawingFigure 1A~1B
  • EP2774031B1 patent drawingFigure 2
  • EP2774031B1 patent drawingFigure 3

AI summary

Metadata-driven undo is described. In an embodiment, a metadata repository stores metadata that is associated with operations. Attributes associated with each operation are also stored in the metadata. Each operation is associated with an undolet that includes instructions for generating undo entries for operations of a particular operation type. Undo log entries are generated using the metadata and the undolet when a request is intercepted that includes an undoable operation. When an undo command is issued, the instructions in the undo log that are associated with a particular business transaction are executed to "rewind" the transaction.