Database Lock Mechanism for Network Partition Tolerance in VCS

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current versioning and revision control systems in high availability networks face challenges with network partitions, leading to inconsistencies and repository corruption due to concurrent writes across distributed nodes, which are difficult to merge and often require human intervention.

Innovation Solution

A database lock mechanism is implemented to prevent concurrent writes during network partitions by locking files on isolated nodes, analyzing actions to determine if updates are necessary, and ensuring only the latest revision is committed, using a lock table to maintain locking information and correct revisions, thereby preventing repository corruption.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If current versioning and revision control system programs are used in distributed node clusters, then nodes can work in parallel and process new information, but network partitions cause repository inconsistencies and divergence that are difficult to merge

Engineering Contradiction:

Improveparallel processing capabilityVSAvoidrepository consistency

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by acquiring locks on repository objects before processing changes and releasing locks after changes are committed. This preliminary locking prevents concurrent modifications during network partitions, ensuring repository consistency while allowing parallel processing when available.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The lock management system acts as an intermediary between distributed nodes and the repository. It mediates access to repository objects by granting or denying lock requests, preventing direct concurrent writes that would cause divergence during network partitions.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Ease of operation

If fixed quorum policies are used in version control systems, then simple write operations are possible, but they are ineffective in maintaining synchronous versions across distributed node clusters

Engineering Contradiction:

Improvewrite operation simplicityVSAvoidsynchronous version maintenance

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

The system dynamically adjusts its behavior based on network conditions and lock availability. Instead of fixed quorum policies, it acquires locks when needed for writes and releases them after commits, adapting to distributed environment conditions to maintain synchronous versions across nodes.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The lock management system provides feedback by tracking lock status and repository state across distributed nodes. This feedback mechanism ensures that write operations are coordinated properly, maintaining synchronous versions even in distributed environments where fixed quorum policies fail.

Inventive Principle:

Principle #23Feedback

3Productivity

If concurrent writes are allowed during network partitions, then nodes remain active and productive, but repository history diverges and merging becomes highly complex requiring human interaction

Engineering Contradiction:

Improvenode activity during partitionVSAvoidmerge operation complexity

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The system applies preliminary anti-action by preventing concurrent writes through lock acquisition before changes are made. This preemptive locking stops the divergence problem before it occurs, keeping nodes productive during partitions while avoiding the complex merge scenarios that would otherwise require human intervention.

Inventive Principle:

Principle #9Preliminary anti-action

4Reliability

If database locks are implemented on per repository basis, then data consistency is maintained during network interruptions, but lock management complexity increases

Engineering Contradiction:

Improvedata consistency during partitionVSAvoidlock mechanism complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The lock management system is segmented into distributed lock managers on each node that independently handle lock requests for their local repositories. This segmentation maintains data consistency during partitions while distributing the complexity management across multiple independent components rather than a single centralized system.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS11334530B2Network partition tolerance in a high available centralized VCS implementation

Publication Date: 2022.05.17 ORACLE INT CORP

AI summary

Implementations provide a database lock mechanism used to prevent concurrent writes to service on network partition scenarios associated with a version control system. The database lock mechanism may be provided on per repository basis to ensure both nodes are working and maintaining data consistency, even when they are not connected when interruptions in network communication disrupts the intercommunication between nodes. In other implementations, the disclosed locking mechanism is configured to ensure and perform write and synchronization operations on isolated nodes, regardless of miss-communication between the nodes.