Dependent Commit Queue for Database Locking Overhead

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Database systems face performance issues due to locking mechanisms that block access and create overhead, especially in high-frequency and long-duration lock scenarios, leading to slow response times and queuing delays.

Innovation Solution

Implementing a conditional commit mechanism that allows database access without locking, enabling writes based on specific conditions and using a dependent commit queue to manage transactions, reducing locking overhead and allowing faster processing even in high-transaction volumes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If locking mechanisms are used to prevent data inconsistencies, then data integrity is improved, but system response time deteriorates due to access blocking and queuing delays

Engineering Contradiction:
Improvedata integrityVSAvoidsystem response time
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The patent applies preliminary action by pre-establishing commit dependencies and ordering relationships between transactions before actual conflicts occur. The system pre-defines the sequence in which commits must be executed based on transaction dependencies, allowing the database to proactively manage commit ordering without requiring blocking locks during transaction execution. This eliminates the need for runtime locking while maintaining data integrity through pre-planned commit sequences.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces a commit dependency graph as an intermediary structure that mediates between conflicting transaction commits. Instead of directly blocking access through locks, the system uses the dependency graph to indirectly coordinate commit ordering. The graph serves as a mediator that tracks and resolves commit dependencies without preventing transaction execution, thus maintaining both data integrity and system responsiveness.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If locking access to database entries is implemented during data manipulation, then data consistency is improved, but device complexity increases due to overhead for tracking locks and managing queues

Engineering Contradiction:
Improvedata consistencyVSAvoidlocking overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the locking mechanism from the commit management process entirely. Instead of using traditional locks to enforce commit ordering, the system removes locks and replaces them with a commit dependency graph that tracks relationships between transactions. This extraction eliminates the complexity of lock acquisition, release, and conflict detection while maintaining data consistency through dependency-based commit sequencing.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent substitutes the mechanical locking system with a logical dependency tracking system. The commit dependency graph uses logical relationships and ordering constraints rather than physical lock mechanisms. This substitution replaces the complex mechanics of lock management with a simpler graph-based approach that tracks commit dependencies without requiring actual blocking or synchronization primitives.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Reliability

If traditional locking mechanisms are used, then data integrity is maintained, but productivity decreases due to queuing delays in high-transaction scenarios

Engineering Contradiction:
Improvedata integrityVSAvoidtransaction processing throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies preliminary action by pre-establishing commit dependencies and ordering relationships between transactions before actual conflicts occur. The system pre-defines the sequence in which commits must be executed based on transaction dependencies, allowing the database to proactively manage commit ordering without requiring blocking locks during transaction execution. This eliminates the need for runtime locking while maintaining data integrity through pre-planned commit sequences.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent enables continuity of useful action by allowing multiple transactions to execute concurrently without being blocked by locking mechanisms. Transactions can proceed with their data manipulation operations continuously, and only the commit phase is coordinated through the dependency graph. This maintains continuous productive work while ensuring eventual consistency through ordered commits, significantly improving throughput compared to traditional locking approaches.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS9846719B2Dependent commit queue for a database
Publication Date: 2017.12.19 MATRIXX SOFTWARE
  • US9846719B2 patent drawing
  • US9846719B2 patent drawing
  • US9846719B2 patent drawing

AI summary

A database comprises a database interface and a database updater. The database interface receives a first set of information and a second set of information to be updated in the database. The database updater updates a second set of information in the database based at least in part on a condition that a first set of information in the database has been previously updated.