# lock-db v0.5.0 — Adversarial Hardening & API Freeze
**No new surface — just proof it holds up.** v0.5.0 adds no public API. It takes
the feature set frozen at v0.4.0 and puts it under adversarial load: a contention
stress test that hammers a shared resource pool from many threads, and a
deadlock-storm test that provokes deadlocks on purpose and checks the manager
always digs out of them. With those in place the public API is recorded as
**frozen until 2.0**.
## What is lock-db?
The lock manager for a transactional database: the component that lets many
transactions touch shared data at once without corrupting it. It hands out locks
across multiple granularities, locks key ranges to stop phantoms, and detects
deadlocks and names a victim to abort. It assigns no identities and persists
nothing; it is the in-memory lock table a transaction layer drives.
## What's new in 0.5.0
### Adversarial contention test
Eight threads run twenty thousand iterations each, every iteration taking a
random shared or exclusive lock on a random resource from a pool of sixteen,
doing a scrap of work, and releasing. Correctness is checked against an
**independent shadow of the lock state** — a per-resource pair of atomic counters
the test maintains itself. A thread that holds an exclusive lock asserts no other
holder is inside the critical section; a thread that holds a shared lock asserts
no writer is. If the manager ever granted two incompatible locks, one of those
asserts would fire. None do.
The assertions are schedule-independent: they must hold for every interleaving,
not just the common ones, so the test is a real invariant check rather than a
coverage exercise.
### Deadlock-storm test
Eight threads each commit a hundred two-resource transactions, acquiring the two
resources in a **random order** drawn from a pool of six. Acquiring two of six
resources in arbitrary order from eight threads is a deadlock generator. Each
thread drives the deadlock-aware [`request`](../API.md#lockmanagerrequest): on a
reported deadlock it aborts and restarts the transaction; on a wait it retries.
The assertion is **liveness**: every transaction the threads set out to commit
does commit. If deadlock detection ever failed to break a cycle, progress would
stall — so the test caps total attempts and the per-wait spin, and fails loudly
rather than hanging if it ever stops making headway. After the storm, no locks
and no waits are left behind, and a final [`find_deadlock`](../API.md#lockmanagerfind_deadlock)
confirms nothing survived.
### Why these and not more loom
`loom` exhaustively explores interleavings but only for tiny models (two or three
threads, a handful of operations); the existing `loom` checks already cover the
core mutual-exclusion and deadlock paths at that scale. These stress tests cover
the opposite end — many threads, many operations, real scheduling — where the
property is statistical coverage of schedules rather than exhaustive proof. The
two approaches are complementary, and the suite now has both.
## API freeze
The public API is **frozen until 2.0**. The complete surface:
- Core (`no_std`): `LockMode`, `KeyRange`, `TxnId`, `ResourceId`, `LockError`.
- `std`: `LockManager`, `Acquisition`, `WaitForGraph`, `VictimPolicy`,
`Deadlock`, and the `prelude`.
No additions or signature changes will land before 2.0; the remaining 0.x
releases integrate against real consumers and capture final benchmarks.
## Breaking changes
**None.** This release adds tests only.
## Verification
Run on Windows x86_64 (Rust stable 1.95) and Linux via WSL2 Ubuntu (Rust stable
1.95); MSRV verified on Rust 1.85. All commands below pass on both platforms:
```bash
cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo clippy --all-targets --all-features -- -D warnings
cargo clippy --no-default-features --all-targets -- -D warnings
cargo test
cargo test --all-features
cargo build --examples
RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features
cargo deny check
cargo audit
# concurrency model checks (slow; not part of the default run)
RUSTFLAGS="--cfg loom" cargo test --test loom --release
```
Test counts at this tag:
- Default features: 90 unit + 38 doctests.
- `--all-features`: 90 unit + 38 doctests + 4 property tests + 2 stress tests.
- `--no-default-features`: 26 unit tests (the `no_std` core).
- Loom: 4 model checks.
`cargo audit` and `cargo deny check` are clean.
## What's next
- **0.6.0 → 1.0.0 — alpha / beta / rc / stable.** Integrate against real
consumers (`txn-db`, `page-db`), broaden testing, capture final benchmarks,
then tag 1.0 and publish.
## Installation
```toml
[dependencies]
lock-db = "0.5"
# with serde derives on the public types
lock-db = { version = "0.5", features = ["serde"] }
```
MSRV: Rust 1.85 (2024 edition).
## Documentation
- [README](https://github.com/jamesgober/lock-db/blob/main/README.md)
- [API Reference](https://github.com/jamesgober/lock-db/blob/main/docs/API.md)
- [CHANGELOG](https://github.com/jamesgober/lock-db/blob/main/CHANGELOG.md)
---
**Full diff:** [`v0.4.0...v0.5.0`](https://github.com/jamesgober/lock-db/compare/v0.4.0...v0.5.0).
**Changelog:** [`CHANGELOG.md`](https://github.com/jamesgober/lock-db/blob/main/CHANGELOG.md#050---2026-06-05).