Source-linked AI summary
HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols
Farzad Habibi, Juncheng Fang, Faisal Nawab
TL;DR
Designing application-specific concurrency-control protocols remains expert-driven and labor-intensive. HakiCC uses a two-stage multi-agent pipeline to design, verify, and optimize protocols for target workloads. On TPC-C and AuctionMark, it reports average throughput gains after Stage 2 optimization.
Problem
Designing a new application-specific concurrency-control protocol remains expert-driven and labor-intensive because correctness, target-workload performance, and implementation correctness must be considered together.
Source: §1 · p. 1Method
HakiCC uses a multi-agent pipeline to generate and repair a workload-specific protocol until verified, then applies LLM-driven evolutionary optimization.
Source: §1 · p. 1Results
All ten protocols pass conflict-serializability verification after Stage 1; Stage 2 reports average throughput gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols.
Source: §7 · p. 12Takeaways & Limitations
HakiCC demonstrates that LLM-driven agentic pipelines can serve as practical tools for concurrency-control protocol design across diverse OLTP workloads.
Source: §7 · p. 12HakiCC establishes correctness empirically rather than by formal proof.
Source: §7 · p. 12
Abstract
from arXiv · showhide
Large language models (LLMs) have recently been applied in systems research as a tool to reduce human-intensive engineering effort through cost-efficient automation. Decades of research have produced a rich landscape of concurrency control (CC) protocols, each encoding distinct trade-offs in correctness, throughput, and abort behavior. However, most applications in practice default to 2PL or OCC, because selecting and adapting a protocol to a specific application requires expert knowledge that is rarely available to application designers. This is a wasted opportunity, as an application-specific CC protocol can yield significant performance advantages over a generic baseline, but designing one requires deep expertise in CC protocol design. In this paper, we propose HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes concurrency control protocols tailored to a given target application. HakiCC provides a two-stage pipeline. In Stage 1, a multi-agent system takes a workload description as input and generates an application-specific CC protocol implementation, which is iteratively repaired and verified for conflict-serializability. In Stage 2, the verified protocol is further optimized for that application through an LLM-driven evolutionary loop targeting correctness and throughput. We evaluate HakiCC on TPC-C and AuctionMark as target workloads, producing and reporting ten application-specific CC protocols. All ten are conflict-serializable after Stage 1; Stage 2 improves throughput for every protocol, with average gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols.
1 Introduction
Designing concurrency control protocols for specific applications remains expert-driven and labor-intensive. HakiCC automates protocol design, verification, and optimization, and its evaluation reports ten conflict-serializable protocols with throughput gains after optimization.
1 Introduction
- Designing application-specific protocols requires expertise to reason jointly about correctness, target-workload performance, and implementation correctness.Existing optimizations also require deep knowledge of transaction logic and concurrency-control mechanisms.Source: §1 · p. 1
- Prior LLM agent and evolutionary capabilities motivate testing whether a pipeline can design, verify, and optimize a protocol without human feedback.The paper poses this as an open question about application-specific concurrency control.Source: §1 · p. 1
- HakiCC takes a target workload as input, generates and repairs an executable protocol until it passes verification, then evolves it through benchmark evaluation.The pipeline uses a multi-agent design stage followed by an LLM-driven evolutionary optimization stage.Source: §1 · p. 1
- All ten generated protocols pass conflict-serializability verification, and their designs span multiple concurrency-control families.TPC-C protocols mostly cluster around OCC/Silo, while AuctionMark protocols include MVCC, deterministic scheduling, OCC-family, and hybrid designs.Source: §1 · pp. 1–2
- +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols are the average throughput gains reported after Stage 2 optimization.Stage 2 improves throughput for most of the ten protocols while maintaining correctness.Source: §1 · p. 2
2 Background and Motivation
Concurrency-control protocols make different trade-offs, while designing new ones remains human-driven and correctness must be checked under concurrent execution. HakiCC applies an LLM-driven evolutionary loop to optimize a protocol produced by its agentic design workflow.
2.1 Database Transactions
- Concurrency-control protocols include 2PL, OCC, MVCC, and SSI, with different trade-offs in blocking, validation overhead, abort rates, and correctness guarantees.Hybrid designs can combine optimistic validation with commutative-operation escrow for counter-heavy workloads.Source: §2.1 · p. 2
- Conflict-serializability can be checked by testing whether the precedence graph for an execution trace is acyclic, but passing verifies observed interleavings rather than all possible schedules.HakiCC uses a heavily concurrent verification suite to try to surface unserializable behavior.Source: §2.1 · p. 2
2.2 LLM-Driven Agentic Optimization
- LLM-driven evolutionary frameworks maintain and mutate candidate populations, evaluate them, and retain high-scoring candidates to explore large design spaces.HakiCC uses this approach to refine a protocol from its agentic design workflow for performance rather than design from scratch.Source: §2.2 · p. 2
- HakiCC’s pipeline generates a workload-based protocol, implements and verifies it, then optimizes the verified protocol against performance benchmarks.The overview depicts failure traces returning to the Generator during Stage 1 and an evolutionary optimizer in Stage 2.Source: Figure 1 · p. 3
3 HakiCC Design
HakiCC uses a two-stage pipeline to design and implement workload-specific concurrency-control protocols, then optimize them through an agentic evolutionary framework. Stage 1 verifies conflict-serializability before protocols advance to Stage 2.
3.1 Stage 1: Proposal Pipeline
- Stage 1 turns a workload specification into an executable, verified conflict-serializable protocol for Stage 2 optimization.Its input is a set of transaction types and stored procedures; Stage 1 typically completes within minutes.Source: §3.1 · p. 3, §3.1.1 · p. 3
3.1.1 Workflow.
- The Proposer specifies protocol rules and correctness rationale; the Generator implements them, and the Verifier checks execution traces for conflict-serializability.The Verifier builds a precedence graph and returns runtime failures or cycles to the Generator for repair; a Novelty Evaluator scores verified designs.Source: §3.1.1 · pp. 3–4
3.1.2 Final Stage 1 Output.
- Stage 1 outputs a runnable protocol as a concrete subclass with a fixed begin/read/write/commit/rollback interface.The shared interface keeps outputs coherent and simplifies benchmarking and verification.Source: §3.1.2 · p. 4
3.1.3 Shared Conversation History.
- Shared conversation history gives downstream agents prior outputs and reasoning; compaction retains the original specification and latest error feedback.When history exceeds a token threshold, older debug entries are summarized and dropped, keeping context size O(1) in repair iterations.Source: §3.1.3 · p. 4, §3.1.4 · p. 4
3.1.5 Termination and Restart.
- Stage 1 restarts if repairs exceed the iteration limit or the protocol’s novelty score falls below a configurable threshold.A restart returns the pipeline to the Proposer with a fresh invocation.Source: §3.1.5 · p. 5
3.2 Stage 2: Agentic Optimization Pipeline
- Stage 2 evolves candidate implementations through targeted edits and evaluates them on correctness and performance workloads.MAP-Elites maintains diverse candidates across islands; the benchmark suite includes TPC-C, AuctionMark, and targeted correctness workloads.Source: §3.2 · p. 5
- Its combined score weighs correctness and throughput equally, with target-application scenarios weighted twice in the throughput measure.Correctness measures the fraction of scenarios that remain conflict-serializable, stall-free, and make measurable progress; the final protocol is filtered for full correctness.Source: §3.2 · p. 5
4 Evaluation
Evaluation tests HakiCC protocols on TPC-C and AuctionMark, examining Stage 1 design diversity and Stage 2 performance. Stage 2 generally improves throughput, while workload-specific comparisons show contention-dependent regressions and phase-level bottlenecks.
4.1 Experimental Setup
- Five protocols per workload are evaluated; TPC-C varies warehouse count and hotspot intensity, while AuctionMark varies Zipfian skew across four contention levels.TPC-C focuses on New Order and Payment in a 50%/50% split; the two transaction types comprise approximately 88% of the benchmark mix.Source: §4 · p. 5, §4.1 · p. 6
4.2 Stage 1 Results
- All ten protocols have distinct multi-axis profiles borrowing from two to four reference families; SALVO, PESC, and PVL form a cross-workload cluster with ≥86% pairwise similarity.Pairwise Jaccard similarity excludes shared absences from the score.Source: §4.2 · p. 7
- SADL, TREAD, and WGC remain structurally separated from peers, with maximum peer similarities of 44%, 48%, and 45%, respectively.SADL has the highest Escrow (48%) and Calvin (45%) similarities among generated protocols.Source: §4.2 · p. 7
4.3 Stage 2 Results
- Stage 2 improves throughput for most generated protocols across both workloads; Figure 6 compares Stage 1 and Stage 2 curves with 2PL and OCC baselines.Throughput is measured in K TPS across six TPC-C contention levels and four AuctionMark contention levels.Source: §4.3 · p. 7, Figure 6 · p. 8
4.3.2 AuctionMark Protocols.
- TREAD’s commit phase falls from 2,412 μs at extreme contention to a 77–367 μs Stage 2 profile; PVL’s Stage 2 commit phase stays at 22–28 μs.Read and write phases remain below 10 μs for most AuctionMark protocols across contention levels.Source: Figure 7 · p. 8, §4.3.2 · p. 9
4.3.1 TPC-C Protocols.
- All five post-Stage 2 TPC-C protocols outperform both 2PL and OCC at medium and higher contention.LP-OCC and DCOV change only −19% to +13%, while SADL and PESC show larger contention-dependent gains.Source: §4.3.1 · pp. 7–8
- Stage 2 cuts SADL’s write phase from 50–2,460 μs to 1.2–3.3 μs and PESC’s commit overhead from 209–891 μs to 25–549 μs.For PESC, the low-contention commit case drops by 8× after redundant validation work is removed from the conflict-free fast path.Source: §4.3.1 · p. 8
4.3.2 AuctionMark Protocols.
- For AuctionMark, TREAD gains +480% at medium contention but regresses −21% at low; HSL alone regresses at all levels (−4% to −14%).PVL improves by +435% at extreme contention, while SAPL gains +18% at low contention but regresses by 32% at high contention.Source: §4.3.2 · pp. 8–9
5 Generated Concurrency Control Protocols
This section presents ten HakiCC-generated concurrency-control protocols: five for TPC-C and five for AuctionMark. Each protocol is described through its design, read/write/commit strategy, and Stage 2 improvements.
5 Generated Concurrency Control Protocols
- The section describes ten HakiCC-generated concurrency-control protocols: five target TPC-C and five target AuctionMark.The protocols are presented individually in the following subsections.Source: §5 · p. 9
- Each protocol receives a design overview and a description of its read, write, and commit strategy.The section also reports improvements found by Stage 2 for each protocol.Source: §5 · p. 9
- The correctness arguments are HakiCC’s conflict-serializability justifications, confirmed by Stage 1 verification.Source: §5 · p. 9
5.1 TPC-C Specific Protocols
The five TPC-C protocols use different combinations of deterministic scheduling, optimistic validation, locks, and commutative updates. Stage 2 repairs implementation defects and adjusts these designs, while the protocols’ correctness arguments rely on their respective ordering or validation mechanisms.
5.1.1 SADL – Semantic-Aware Deterministic Locking.
- SADL assigns transactions a per-partition serial order and uses shared, exclusive, and ordered-commutative locks; Stage 2 fixes three concurrency defects that suppressed throughput.Cross-partition transactions remain correct but do not benefit from independent per-partition scheduling.Source: §5.1.1 · p. 9
5.1.2 SALVO – Semantic-Aware Latching and Optimistic Delta Ap-
- SALVO combines OCC versioned reads with atomic counter increments, blind-read elimination, commutative deltas, and private inserts; Stage 2 broadens delta handling and fixes checkpoint replay.Its conflict-serializability argument combines OCC validation with order-independent deltas and sorted-order commit locking.Source: §5.1.2 · p. 9
5.1.3 LP-OCC – Lock-Protected Optimistic Concurrency Control.
- LP-OCC briefly locks each key during reads, buffers writes, and locks the read/write set at commit for atomic validation and installation.Stage 2 removes avoidable commit-path overhead and routes writes through matching store operations.Source: §5.1.3 · pp. 9–10
5.1.4 PESC – Phased Execution and Semantic Commit.
- PESC routes commutative fields to signed deltas and other fields to buffered values, with validation and sorted per-key locks supporting conflict-serializability.Stage 2 removes an untracked counter-write bypass and narrows locking to write keys.Source: §5.1.4 · p. 10
5.1.5 DCOV – Dual-Counter Optimistic Validation.
- DCOV tracks exclusive and commutative modifications with separate counters and validates both for every non-blind read under a per-warehouse commit lock.Stage 2 adds a validation-result cache, removes unnecessary synchronization on private data structures, and fixes partition-key parsing.Source: §5.1.5 · p. 10
5.2 AuctionMark Specific Protocols
The AuctionMark protocols span speculative locking, multi-version reads, pre-execution scheduling, and version-validated commits. Their designs use different mechanisms to order conflicting work or detect changes before committing.
5.2.1 HSL – Hierarchical Speculative Locking.
- HSL lets transactions execute speculatively without locks, then uses entity-level firm locks and proactive invalidation to prevent commits based on stale reads.Stage 2 expands entity-prefix coverage to reduce false conflicts from keys otherwise mapped to a global lock entity.Source: §5.2.1 · p. 10
5.2.2 TREAD – Transactional Read Epoch-based Abort & Deltas.
- TREAD serves non-blocking snapshot reads, tracks dependencies on item-status versions, and uses commutative deltas for selected counters.Stage 2 narrows dependency invalidation to the current version head, reducing its per-key cost from O(V) to O(1).Source: §5.2.2 · pp. 10–11
5.2.3 WGC – Workflow-Aware Graph Coloring.
- WGC classifies transactions by write behavior and schedules them at single-threaded entity coordinators, allowing overlap only under its color-compatibility rules.Stage 2 replaces active-transaction scans with per-color counts and re-evaluates waiting transactions in FIFO order.Source: §5.2.3 · p. 11
5.2.4 PVL – Optimized Phased Validation Locking.
- PVL uses lock-free reads and three commit paths for read-only, delta-only, and standard transactions, validating version snapshots on each path.Stage 2 fixes numeric type handling that caused spurious aborts.Source: §5.2.4 · p. 11
6 Related Work
Related work covers established concurrency-control families, hybrid and learned protocols, and LLM-driven agents and evolutionary optimization. HakiCC is distinguished by generating application-specific protocol implementations and pairing them with serializability verification and evolutionary refinement.
6 Related Work
- Established CC families and systems target different hardware or workload conditions, but adapting them to a new workload requires manual re-engineering.The section discusses 2PL, OCC, MVCC, SSI, in-memory protocols, and deterministic protocols.Source: §6 · pp. 11–12
- Hybrid approaches combine or select protocols, but generally focus on 2PL and OCC, depend on programmer-supplied heuristics, and do not exploit application-level transaction semantics.HakiCC instead generates a complete application-specific protocol implementation.Source: §6 · p. 12
- Learned CC systems search or learn policies over fixed action spaces, whereas HakiCC uses LLM agents to generate protocols tailored to application semantics.Source: §6 · p. 12
- General agentic coding systems validate with unit tests, which cannot certify CC protocol correctness; HakiCC pairs specialized agents with a serializability verifier.Source: §6 · p. 12
- HakiCC applies LLM-driven evolutionary refinement to CC implementations, using correctness and throughput as joint objectives.It builds on evolutionary methods that use LLMs to propose program mutations guided by feedback.Source: §6 · p. 12
7 Conclusion
HakiCC generated ten application-specific protocols for TPC-C and AuctionMark, verifying all for conflict-serializability after Stage 1. Stage 2 improved combined correctness-throughput scores for nine protocols, and the protocols span multiple design families; correctness was established empirically, not by formal proof.
7 Conclusion
- Stage 1 verified conflict-serializability for all ten protocols; Stage 2 improved combined correctness-throughput scores for nine of ten, with average throughput gains of +50.6% (TPC-C) and +92.2% (AuctionMark).Source: §7 · p. 12
- The ten protocols span pessimistic, optimistic, versioned, deterministic, and semantic design families rather than converging on one template.Source: §7 · p. 12
- Correctness is established empirically rather than by formal proof; extending HakiCC to distributed protocols is a proposed next step.Source: §7 · p. 12