Four-Stage Transaction Management Framework

• The paper introduces a four-stage transaction management framework that guarantees conflict serializability and employs adaptive locking with timeout-based deadlock prevention.
• It leverages precise transaction lifecycle management, operation classification, and pre-execution conflict detection to reduce locking overhead and minimize abort rates.
• Experimental evaluations show significant throughput gains and latency reductions, demonstrating improved performance over baseline NoSQL transaction approaches.

A four-stage transaction management framework, as introduced by Alflahi et al. (Alflahi et al., 23 Jan 2026), is an extensible protocol for ensuring consistent and scalable transactions within document-oriented NoSQL databases. Using MongoDB as its reference platform, the framework integrates: precise transaction lifecycle control, operation type classification, proactive pre-execution conflict detection, and adaptive locking with timeout-based deadlock prevention. It guarantees conflict serializability under a formally analyzed model and demonstrates significant performance benefits under high concurrency and distributed workloads.

1. Four-Stage Design and Operation

The framework operates sequentially through four key stages, each contributing to data integrity and performance:

Stage 1: Transaction Lifecycle Management

This stage assigns a unique context to each transaction, encapsulated as $$TC = (id, ts, state, readSet, writeSet, retryCount, maxRetries)$$, where $id$ is a UUID, $ts$ is a monotonic timestamp, and $$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$. Transactions progress through these states, enabling retries and rollback as appropriate.

Stage 2: Operation Classification

Here, transactions are classified in terms of their read and write sets:

• $R(T) = \{d \mid T$ reads document $d\}$
• $W(T) = \{d \mid T$ writes document $d\}$ Classification:
• If $W(T)=\emptyset$: READ (shared locks)
• If $R(T)=\emptyset$: WRITE (exclusive locks)
• Otherwise: HYBRID (exclusive locks over $id$0) This discrimination reduces locking overhead for read-only and write-only operations.

Stage 3: Pre-execution Conflict Detection

Utilizing a lock table $id$1, the system assesses:

• Write–Write: $id$2 s.t. $id$3 holds an exclusive lock (X-lock) by another transaction.
• Read–Write: $id$4 s.t. $id$5 holds/pending X-lock by another transaction. Upon conflict, the transaction enters WAITING and is retried later; otherwise, it transitions to READY.

Stage 4: Adaptive Locking with Timeout-Based Deadlock Prevention

Strict two-phase locking (S2PL) is implemented, with transactions acquiring all locks before execution and releasing them only at commit/abort. Locks are requested in sorted document ID order. The protocol employs:

• Maximum lock timeout $id$6 ms
• Initial backoff $id$7 ms, max backoff $id$8 ms, with random jitter. If a transaction cannot acquire its locks within $id$9, it is aborted (or retried, subject to $ts$0).

2. Formal Definitions and Serializability Guarantees

Transaction Context and State Machine

A transaction’s context is specified as $ts$1 with state transitions:

• $ts$2
• $ts$3 (conflicts) or $ts$4 (no conflicts)
• $ts$5 (retry)
• $ts$6
• $ts$7

Conflict Serializability

Conflict serializability is defined: a schedule $ts$8 is conflict-serializable if it is conflict-equivalent to some serial schedule. Under this framework, all committed transactions form a conflict-serializable schedule. The proof rests on:

• S2PL: locks are acquired before any data operation, held until commit/abort, never released early.
• Global lock acquisition order (document ID): enforces deterministic ordering, eliminating cycles.

Deadlock Freedom

Timeout-bounded lock acquisition ensures deadlock freedom. The adaptive model:

• Caps lock wait time at $ts$9, aborting transactions that cannot proceed, thus breaking potential wait-for cycles.

3. Main Algorithmic Components

The implementation is modular, comprising:

Component	Function	Key Parameterization
Lifecycle Manager	Initializes transaction context	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$0, UUID, ts, retry metadata
Operation Classifier	Assigns transaction type and sets	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$1, $$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$2, type, lock mode
Conflict Detector	Checks lock table for conflicts	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$3, sets, type
Lock Manager	Executes transaction with adaptive locking	Timeout, backoff, sorting order

Pseudocode:

$W(T) = \{d \mid T$0

4. Correctness Arguments and Theoretical Properties

The framework’s correctness stems from:

• Strict Two-Phase Locking (S2PL) enforced via middleware
• Fixed global ordering on lock acquisition
• Pre-execution conflict detection These combined ensure no interleaving of conflicting operations among concurrent transactions. Timeout-driven deadlock prevention interrupts cycles in the wait-for graph within bounded elapsed time.

5. Experimental Evaluation and Performance Metrics

Empirical validation spans single-node and distributed MongoDB deployments.

Methodology

• Java 8 middleware, MongoDB 4.2.8, majority/linearizable concerns
• YCSB v0.17, workloads: A (50% read, 50% write), B (95% read, 5% write), F (50% read, 50% read-modify-write)
• Clients: 1–100; Dataset: 10K–10M records; Cluster: up to 9 nodes

Key Metrics

Metric	Definition
Throughput	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$4
Abort rate	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$5
Latency var.	$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$6(latency$$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$7)
P99 latency	99th percentile latency
Deadlock count	Number of observed deadlocks

Results

Single-node, 15 clients, Workload F:

• Abort rate reduced: $$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$8 ($$state \in \{\text{PENDING}, \text{CLASSIFIED}, \text{WAITING}, \text{READY}, \text{EXECUTING}, \text{COMMITTED}, \text{ABORTED}\}$$9)
• Deadlocks: $R(T) = \{d \mid T$0 ($R(T) = \{d \mid T$1 elimination)
• Latency std. dev.: $R(T) = \{d \mid T$2 ms $R(T) = \{d \mid T$3 ms ($R(T) = \{d \mid T$4)
• P99 latency: $R(T) = \{d \mid T$5 ms $R(T) = \{d \mid T$6 ms ($R(T) = \{d \mid T$7)
• Throughput uplift: up to $R(T) = \{d \mid T$8 under high concurrency

Distributed, 9-node cluster, Workload F:

• Throughput: $R(T) = \{d \mid T$9 ops/s $d\}$0 ops/s ($d\}$1)
• Abort rate: $d\}$2 ($d\}$3)

Parameter Sensitivity

• Optimal lock timeout: $d\}$4 ms
• Initial backoff: $d\}$5 ms
• Max backoff: $d\}$6 ms

6. Comparative Analysis with Baseline Systems

The framework was benchmarked against baseline MongoDB, MongoDB native transactions, CockroachDB 21.2, and TiDB 5.3 under identical workload and client profiles.

System	Throughput (ops/s)	P50 Latency (ms)	P99 Latency (ms)	Abort Rate (%)
Baseline MongoDB	2,920	28.5	125.6	8.3
Four-stage (Alflahi)	3,390	31.2	98.4	4.7
MongoDB native Txn	2,450	45.8	245.8	2.1
CockroachDB	2,780	35.6	156.7	3.5
TiDB	2,650	38.2	178.9	4.2

Relative improvements vs. baseline MongoDB:

• Throughput: $d\}$7
• P99 latency: $d\}$8
• Abort rate: $d\}$9

7. Context and Significance

The four-stage transaction management framework demonstrates that combining lifecycle tracking, nuanced operation classification, proactive pre-execution conflict detection, and adaptive locking with bounded deadlock prevention can significantly improve both the consistency and scalability of document-oriented NoSQL systems. The key results — decreased abort rates, deadlock elimination, and substantial throughput gains — suggest that practical document-oriented databases can approach the consistency guarantees of classical ACID systems while retaining performance advantages. A plausible implication is that similar staged transaction control designs may generalize to other NoSQL platforms employing eventual consistency or partial isolation, providing a basis for improved middleware-level transaction correctness (Alflahi et al., 23 Jan 2026).