Logical Transaction ID for Database Idempotence

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems fail to provide reliable information about the outcome of database transactions during outages, leading to duplicate submissions and logical corruption, as they lack mechanisms to track and manage transactional states across sessions.

Innovation Solution

The implementation of a Logical Transaction ID (LTXID) system that tracks and manages transactional states, ensuring idempotence by blocking uncommitted transactions and allowing at-most-once execution semantics, even across multiple sessions and servers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the client resubmits transactions after a connection failure, then the system maintains availability and can recover from outages, but duplicate transactions may be executed causing logical corruption

Engineering Contradiction:
Improvetransaction integrityVSAvoidsystem availability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The server sends a Logical Transaction ID (LTXID) back to the client after each transaction commit. The client uses this LTXID to track which transactions have been successfully committed. After a connection failure, the client can query the server with the LTXID to get feedback on whether the transaction was committed, preventing duplicate submissions while maintaining availability.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The LTXID acts as an intermediary mechanism between the client and server. It carries transaction state information across connection boundaries, enabling the client to determine whether to resubmit transactions after failures without directly querying transaction state, thus preventing duplication while preserving system availability.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the server tracks transaction states across sessions using LTXID, then duplicate submissions are prevented, but the system complexity increases

Engineering Contradiction:
Improveidempotence enforcementVSAvoidtransaction tracking mechanism
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the transaction state tracking functionality from the complex session management system and encapsulates it in a simple LTXID mechanism. The LTXID is a single identifier that carries all necessary state information, separating the tracking concern from the broader transaction processing system and reducing overall complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The LTXID serves multiple functions: it uniquely identifies a transaction, tracks its commit state, enables idempotence checking, and facilitates session recovery. This multi-functional approach consolidates what would otherwise require multiple separate mechanisms into a single simple identifier, reducing system complexity.

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

3Reliability

If the server blocks uncommitted transactions across sessions, then data consistency is maintained, but the processing speed decreases

Engineering Contradiction:
Improvedata consistencyVSAvoidtransaction processing speed
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The server performs a preliminary check using the LTXID to determine whether a transaction has already been committed before allowing it to proceed. This early detection mechanism prevents unnecessary processing of duplicate transactions and blocks only when truly needed, maintaining data consistency without significantly impacting normal transaction processing speed.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8924346B2Idempotence for database transactions
Publication Date: 2014.12.30 ORACLE INT CORP
  • US8924346B2 patent drawing
  • US8924346B2 patent drawing
  • US8924346B2 patent drawing

AI summary

A method, machine, and computer-readable medium is provided for managing transactional sets of commands sent from a client to a server for execution. A first server reports logical identifiers that identify transactional sets of commands to a client. The first server commits information about a set of commands to indicate that the set has committed. A second server receives, from the client, a request that identifies the set based on the logical identifier that the client had received. The second server determines whether the request identified the latest set received for execution in a corresponding session and whether any transactions in the set have not committed. If any transaction has not committed, the second server enforces uncommitted state of the identified set by blocking completion of the identified set issued in the first session. The identified set may then be executed in the second session without risk of duplication.