Stateless Data Provider for Transactional Integrity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current business applications face performance issues due to the need to preserve state and transactional buffering across multiple layers in the backend, consuming system resources and impacting overall performance.

Innovation Solution

A system comprising a user interface module, a fast data provider module, and a transaction provider module that allows stateless data reading and transactional data storage, minimizing the need for updating operations and reducing the amount of data offered transactionally, with automatic switching to transactional data provision upon user updates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If state and transactional buffering are preserved across multiple backend layers, then transactional integrity is maintained, but system resources (memory, processing time, communication steps) are consumed

Engineering Contradiction:
Improvetransactional integrityVSAvoidsystem resources
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The system segments the backend into distinct layers: a stateless data access layer that retrieves data without maintaining transactional state, and a transactional layer that handles consistency checks and buffering only when necessary. This segmentation allows the majority of data operations to proceed without consuming transactional resources, while still maintaining integrity where needed.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of maintaining transactional state for all data operations, the system applies transactional buffering partially - only when data is being modified or when consistency checks are required. For read-only operations, the stateless approach is used, consuming minimal resources while maintaining sufficient data access capabilities.

Inventive Principle:
Principle #16Partial or excessive action

2Reliability

If all data is provided transactionally through multiple backend layers, then data consistency is ensured, but the number of communication steps and processing time increase

Engineering Contradiction:
Improvedata consistencyVSAvoidprocessing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system separates data retrieval operations from data modification operations in terms of transactional handling. Read operations use a streamlined stateless path with minimal communication steps, while write operations engage the full transactional layer. This segmentation reduces average processing time while maintaining consistency for critical operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system introduces an intermediary mechanism that determines whether a given operation requires full transactional handling or can proceed through a simplified stateless path. This mediator layer evaluates the operation type and data state, routing requests appropriately to balance consistency requirements with processing efficiency.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If state is maintained across all backend layers, then transactional access is supported, but memory consumption increases

Engineering Contradiction:
Improvetransactional accessVSAvoidmemory
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The system segments memory usage by creating a stateless data access layer that does not maintain transactional state in memory, and a minimal transactional layer that only buffers data when actively processing modifications. This segmentation dramatically reduces overall memory consumption while preserving transactional access capabilities where required.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of maintaining persistent state across all layers, the system uses temporary, short-lived data structures that are created only when needed for specific operations and discarded afterward. This approach minimizes memory footprint while maintaining the necessary transactional functionality for the duration of each operation.

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

Data Source

PatentUS8209281B2Systems and methods for processing data objects
Publication Date: 2012.06.26 SAP SE
  • US8209281B2 patent drawing
  • US8209281B2 patent drawing
  • US8209281B2 patent drawing

AI summary

A system and method for processing data objects is provided. The system and method may comprise a user interface module, a fast data provider module, and a transaction provider module, which modules are configured to exchange data and which may be distributed over a plurality of interconnected servers. Data objects may be statelessly read from a database by the fast data provider module and, after an amendment of the data via the user interface module, statefully saved by the transaction provider module.