Sessionless Transaction Handling for Stateless Database Commit Flow

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing database systems face inefficiencies in resource utilization and flexibility due to the tight coupling of transactions with connections and sessions, particularly in long-running transactions, limiting the ability to decouple sessions from transactions and leading to high transaction latency and inflexible application logic.

Innovation Solution

Implementing 'Sessionless' transactions that allow transactions to be multiplexed between database sessions and connections, using native mechanisms to start, suspend, and resume transactions, enabling efficient resource utilization and load balancing across database server instances, and eliminating the need for external transaction managers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If transactions are tightly coupled with connections and sessions, then resource management is simplified, but resource utilization efficiency deteriorates in long-running transactions

Engineering Contradiction:

Improveresource utilization efficiencyVSAvoidtransaction management complexity

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The patent segments the transaction lifecycle into distinct phases: transaction start, unit of work execution, suspension, and resumption. This allows the transaction to be separated from the session connection, enabling the session to be released and reused while the transaction state is preserved independently in the database.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent extracts the transaction state from the session connection by implementing persistent transaction state storage in the database. This extraction allows transactions to continue without holding onto session resources, enabling efficient resource utilization while maintaining transaction integrity.

Inventive Principle:

Principle #2Taking out (Extraction)

2Reliability

If sessions are held for long-running transactions, then transaction state is maintained, but server-side resources are blocked and unavailable

Engineering Contradiction:

Improvetransaction state consistencyVSAvoidresource availability time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent implements preliminary actions by pre-defining units of work that can be executed independently. These units are prepared in advance and can be resumed later without requiring the original session to remain active, ensuring transaction state consistency while freeing resources for other uses.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent creates a persistent copy of the transaction state in the database, independent of the session connection. This copying mechanism allows the transaction to be suspended and resumed using different sessions while maintaining state consistency, preventing resource blocking.

Inventive Principle:

Principle #26Copying

3Adaptability or versatility

If application logic is embedded in server-side procedures, then transaction management is centralized, but flexibility and ease of modification deteriorate

Engineering Contradiction:

Improveapplication logic flexibilityVSAvoiddeployment complexity

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent inverts the traditional architecture by moving transaction management capabilities from the server side to the client side. The client can now initiate, suspend, and resume transactions independently, while the database provides the necessary state persistence. This inversion greatly improves flexibility as application logic can be modified without server deployment.

Inventive Principle:

Principle #13The other way round (Inversion)

4Reliability

If multiple REST calls are used for complex operations, then stateless protocols are maintained, but transaction atomicity and performance deteriorate

Engineering Contradiction:

Improvetransaction atomicityVSAvoidoperation performance

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent merges multiple separate REST calls into a single atomic transaction by allowing the client to initiate one transaction that can include multiple units of work. This combining approach maintains the stateless REST protocol benefits while ensuring transaction atomicity across multiple operations, improving both reliability and performance.

Inventive Principle:

Principle #5Merging (Combining)

Data Source

PatentUS20260064661A1Sessionless transactions

Publication Date: 2026.03.05 ORACLE INT CORP

AI summary

Techniques for processing “Sessionless” transactions are provided. In one technique, a commit transaction instruction (that includes a transaction identifier) is received from a requesting entity at a first instance of a database server. In response a prepare message is transmitted to a second instance of the database server. A response that indicates that the second instance successfully performed an action in response to the prepare message is received from the second instance based on the prepare message. After the response is received, a transaction that is identified by the transaction identifier is committed. A response, to the commit transaction instruction, that indicates that the transaction is committed is transmitted to the requesting entity. Other techniques include piggybacking transaction instructions with database operation instructions and allowing different database server instances to perform work for a single transaction.