Skip to main content

Module locking

reddb::runtime

Module locking 

Source
Expand description

Intent-lock hierarchy adapter — Resource naming + LockerGuard RAII.

Thin layer over crate::storage::transaction::lock::LockManager that gives the runtime dispatch paths a typed API:

  • Read dispatch: (Global, IS) → (Collection, IS)
  • Write dispatch: (Global, IX) → (Collection, IX)
  • DDL dispatch: (Global, IX) → (Collection, X)

The adapter owns:

  1. A Resource enum that maps the two hierarchy levels to the byte-key format LockManager expects (no string collisions, cheap encoding).
  2. A LockerGuard that records each (resource, mode) pair in acquisition order and releases them on drop. Releases run in reverse order so the global lock is the last to go.
  3. A tiny monotonic TxnId allocator keyed by the current connection id — enough for deadlock detection to distinguish concurrent acquirers.

The adapter does not implement ordered-acquire enforcement via phantom types yet (TODO for P1.T4); callers currently discipline themselves by always going Global → Collection.

Structs§

LockerGuard
RAII guard over a set of acquired locks. Drop releases every acquired resource in reverse-acquire order, so the common Global → Collection path releases Collection first then Global.

Enums§

AcquireError
Outcome of a try_acquire — Granted / Upgraded fall through to the guard, the rest bubble up as an error the caller can log or retry.
Resource
Hierarchical resources the runtime locks on. The byte-key encoding prefixes each level with a discriminator so Collection("global") can never collide with the true global-scope Resource::Global.

Functions§

fresh_txn_id