Escrow Queue Decouples Transaction Commit from Message Delivery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing B2B integration frameworks face reliability issues due to hardware and software faults, leading to transaction delays and deadlocks, especially when long transactions hold resources and cause bottlenecks, and failures result in duplicate message errors.

Innovation Solution

Implementing a persistent FIFO queue and escrow process outside the primary transaction, where messages are stored until successfully sent, allowing the transaction to commit without waiting for message delivery, and the escrow process retries failed message sends.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If messages are sent synchronously within the primary transaction, then message delivery reliability is improved, but transaction performance deteriorates due to resource bottlenecks and deadlocks

Engineering Contradiction:
Improvemessage delivery reliabilityVSAvoidtransaction performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The message sending operation is extracted from the primary transaction and placed in a separate escrow process. The transaction commits without waiting for message delivery, while the escrow process independently manages message sending and retry logic, thus eliminating the performance bottleneck while maintaining reliability

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

A persistent FIFO queue is introduced as an intermediary between the transaction and the message sending operation. The queue decouples the transaction commit from message delivery, allowing the transaction to complete quickly while the escrow process handles message sending asynchronously

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the transaction waits for message delivery confirmation, then message delivery reliability is improved, but transaction commit time increases

Engineering Contradiction:
Improvemessage delivery confirmationVSAvoidtransaction commit time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Message delivery confirmation is obtained in advance before the transaction commits. The escrow process sends messages and retrieves confirmations prior to transaction commit, ensuring reliability without delaying the transaction commit itself

Inventive Principle:
Principle #10Preliminary action

3Stability of the object's composition

If resources are held during the entire transaction duration, then data consistency is improved, but system throughput deteriorates due to bottlenecks

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem throughput
Core Design Contradiction:
Stability of the object's compositionVSProductivity

Solution Approach 1:

The message sending operation that holds resources is extracted from the critical transaction path. Resources are released at transaction commit time rather than being held until message delivery completes, significantly improving system throughput while maintaining data consistency through the escrow process's independent error handling

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS8170896B2System and method for electronic business transaction reliability
Publication Date: 2012.05.01 ORACLE INT CORP
  • US8170896B2 patent drawing
  • US8170896B2 patent drawing
  • US8170896B2 patent drawing

AI summary

A system and method for performing a business transaction including delivering a business message, comprising providing in a first transaction the business message to a first workflow process; transferring the business message from the first workflow process to a second process wherein the transfer is not part of the first transaction; wherein the business message is transferred to the second process using a protocol; and wherein transferring the business message to the second process will be successful even if the first workflow process abnormally terminates.