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 $R(T) \cup W(T)$) This discrimination reduces locking overhead for read-only and write-only operations.

Stage 3: Pre-execution Conflict Detection

Utilizing a lock table $L$, the system assesses:

• Write–Write: $\exists d \in W(T)$ s.t. $L(d)$ holds an exclusive lock (X-lock) by another transaction.
• Read–Write: $\exists d \in R(T)$ s.t. $L(d)$ 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 $T_{\text{max}} = 100$ ms
• Initial backoff $b_0 = 10$ ms, max backoff $b_{\text{max}} = 500$ ms, with random jitter. If a transaction cannot acquire its locks within $T_{\text{max}}$, it is aborted (or retried, subject to $maxRetries$).

2. Formal Definitions and Serializability Guarantees

Transaction Context and State Machine

A transaction’s context is specified as $TC = (id, ts, R, W, state)$ with state transitions:

• $\text{PENDING} \rightarrow \text{CLASSIFIED}$
• $\text{CLASSIFIED} \rightarrow \text{WAITING}$ (conflicts) or $\text{READY}$ (no conflicts)
• $\text{WAITING} \rightarrow \text{CLASSIFIED}$ (retry)
• $\text{READY} \rightarrow \text{EXECUTING}$
• $$\text{EXECUTING} \rightarrow \{\text{COMMITTED}, \text{ABORTED}\}$$

Conflict Serializability

Conflict serializability is defined: a schedule $S$ 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 $T_{\text{max}}$, 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	$TC$, UUID, ts, retry metadata
Operation Classifier	Assigns transaction type and sets	$R(T)$, $W(T)$, type, lock mode
Conflict Detector	Checks lock table for conflicts	$L$, sets, type
Lock Manager	Executes transaction with adaptive locking	Timeout, backoff, sorting order

Pseudocode:

Function InitializeTransaction(request T): TC.id ← UUID() TC.timestamp ← MonotonicTime() TC.state ← PENDING TC.retryCount ← 0 Register(TC) return TC Function Classify(TC): hasReads ← ∃read in TC hasWrites ← ∃write in TC if hasReads and hasWrites: TC.type ← HYBRID TC.readSet ← all reads TC.writeSet ← all writes TC.lockMode ← EXCLUSIVE else if hasWrites: TC.type ← WRITE; TC.writeSet ← all writes; TC.lockMode ← EXCLUSIVE else: TC.type ← READ; TC.readSet ← all reads; TC.lockMode ← SHARED return TC Function DetectConflicts(TC): conflicts ← ∅ if TC.type ∈ {WRITE, HYBRID}: for d in TC.writeSet: if L(d).mode=EXCLUSIVE and L(d).H ≠ {TC.id}: conflicts ∪= {(d, L(d).H)} if TC.type ∈ {READ, HYBRID} and conflicts=∅: for d in TC.readSet: if L(d).mode=EXCLUSIVE and L(d).H ≠ {TC.id}: conflicts ∪= {(d, L(d).H)} return conflicts Function ExecuteTransaction(TC): if DetectConflicts(TC) ≠ ∅: schedule retry or abort else: docs ← sort(TC.readSet ∪ TC.writeSet) for d in docs: lockType ← (if d∈writeSet then EXCLUSIVE else SHARED) if AcquireLockWithTimeout(d,TC.id,lockType)==FAILURE: abort and release all locks perform all reads and writes commit release all locks

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	$(\text{total ops})/(\text{measured time})$
Abort rate	$(\#\text{aborted})/(\#\text{submitted})$
Latency var.	$\text{Var}$(latency$_i$)
P99 latency	99th percentile latency
Deadlock count	Number of observed deadlocks

Results

Single-node, 15 clients, Workload F:

• Abort rate reduced: $8.3\% \to 4.7\%$ ($-43.4\%$)
• Deadlocks: $3 \to 0$ ($100\%$ elimination)
• Latency std. dev.: $12\,450$ ms $\to 8\,194$ ms ($-34.2\%$)
• P99 latency: $245.8$ ms $\to 161.2$ ms ($-34.4\%$)
• Throughput uplift: up to $+18.4\%$ under high concurrency

Distributed, 9-node cluster, Workload F:

• Throughput: $21\,800$ ops/s $\to 27\,560$ ops/s ($+26.4\%$)
• Abort rate: $31.5\% \to 14.8\%$ ($-53.0\%$)

Parameter Sensitivity

• Optimal lock timeout: $100$ ms
• Initial backoff: $10$ ms
• Max backoff: $500$ 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: $+16.1\%$
• P99 latency: $-21.7\%$
• Abort rate: $-43.4\%$

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).