Module fence 

Per-operation maintenance-fence guards.

The SQLite stores deliberately hold no long-lived connection (or, where they do, still perform discrete operations), so a fence honored only at realm open cannot quiesce them: a process that opened its store before the fence was acquired would keep writing straight through it. The fence is therefore enforced per operation: every store operation takes a OperationGuard (a shared OS file lock co-located with the database file), and offline migration takes the ExclusiveFence and waits for outstanding guards and in-flight operations to drain before touching bytes. Stores built on this crate get this for free — which is also why no store may roll its own opener.

Lock files live next to the database as <file>.mfence. They are advisory OS locks (flock on unix, LockFileEx on Windows), cheap to take per operation, and correct across processes as well as between handles in one process.

Fail-open rule: a medium where the lock file cannot be created (read-only snapshot mounts, for example) is a medium where no fence can be held either, so guard acquisition degrades to a no-op there. If the lock file exists and is exclusively held, acquisition fails with the typed SqliteStoreError::MaintenanceFenceHeld — storage is under offline maintenance and the operation must not proceed.

The ConnectionProfile::Maintenance profile is the fence holder’s profile; maintenance work runs under the exclusive fence and does not take shared guards.

Structs

ExclusiveFence

The exclusive side of the maintenance fence for one database file.

OperationGuard

RAII shared guard for one store operation on one database file.

Constants

FENCE_LOCK_SUFFIX

Suffix appended to a database file name to form its fence lock file.

Functions

fence_lock_path

The fence lock file for a database path: <file>.mfence.