Asynchronous Write Request Management for Collaborative Data

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing collaborative data interaction frameworks face challenges in managing read and write requests efficiently, leading to increased latency and reliability issues when multiple users simultaneously access and modify data, as they struggle to provide the most updated versions of shared data objects while processing write requests.

Innovation Solution

The implementation of asynchronous write request management and partially decoupled read request management, where write requests are processed independently of read requests, and read requests are delayed until unprocessed write requests are processed or a waiting period expires, reducing read request processing latency without compromising data reliability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If read requests are processed immediately without waiting for write requests, then read request processing latency is reduced, but data reliability deteriorates as reads may return outdated versions

Engineering Contradiction:
Improveread request processing latencyVSAvoiddata reliability
Core Design Contradiction:
Loss of timeVSReliability

Solution Approach 1:

The system performs preliminary actions by checking the unprocessed write request ledger before processing read requests. This preliminary check determines whether write requests are already in progress, allowing the system to proactively decide whether to wait or proceed with the read operation, thus preventing outdated data retrieval while avoiding unnecessary delays

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback mechanisms by continuously monitoring the state of the unprocessed write request ledger and using this information to dynamically adjust read request processing. The match status determination and conditional waiting create a feedback loop that ensures read requests only proceed when it's safe to do so, maintaining data reliability while minimizing latency

Inventive Principle:
Principle #23Feedback

2Reliability

If the system waits for all write requests to be processed before handling read requests, then data reliability is improved, but read request processing latency increases

Engineering Contradiction:
Improvedata reliabilityVSAvoidread request processing latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system applies partial action by not waiting for all possible write requests before processing reads. Instead, it waits only for the specific write requests identified in the unprocessed write request ledger that are relevant to the current read request. This partial waiting approach provides just enough synchronization to ensure data reliability while avoiding excessive delays

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

By performing preliminary checks of the write request ledger before read operations, the system can determine in advance whether waiting is necessary. This preliminary action allows the system to make informed decisions about waiting duration, ensuring reliability only when needed and reducing latency when write requests have already been processed

Inventive Principle:
Principle #10Preliminary action

3Reliability

If the system uses synchronous write request processing, then data reliability is improved, but system complexity and processing overhead increase

Engineering Contradiction:
Improvedata reliabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the write request processing by maintaining a separate unprocessed write request ledger that is independent of the main data storage. This segmentation allows the ledger to be checked and updated separately without blocking read operations on the actual data, reducing system complexity while maintaining the ability to ensure data reliability through coordinated processing

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The unprocessed write request ledger serves as an intermediary structure that mediates between write and read operations. Rather than having reads directly synchronize with writes through complex locking mechanisms, the ledger acts as an intermediary information source that both read and write operations can consult, simplifying the overall system architecture while maintaining data consistency

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11461040B2Asynchronous write request management
Publication Date: 2022.10.04 ATLASSIAN PTY LTD
  • US11461040B2 patent drawing
  • US11461040B2 patent drawing
  • US11461040B2 patent drawing

AI summary

Systems and methods provide techniques for more effective read/write management in collaborative data interaction frameworks. In response, embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to enable effective and efficient read/write management in collaborative data interaction frameworks. For example, certain embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to read/write management in collaborative data interaction frameworks using techniques that utilize asynchronous write request management along with partially decoupled read request management.