Multi-process operation

An ordinary SQLStyle database open starts the internal work required by that database. Applications do not initialize a separate runtime or send SQL through a local daemon. When several operating-system processes open the same database file, every process still uses SQLite directly and the group presents one node to the controller.

Cross-process coordination lives in a per-database shared memory. It contains the capture ring, WAL and DBH progress, lifecycle state, and a compact copy of the current controller grant.

One process owns capture for each database

The shared memory reserves one open-file-description lock for the capture-host lease. Exactly one process holds that lease for a database. That process owns the services that require one local coordinator: the controller session, WAL capture, DBH workers, replication connections, and terminal shutdown.

Other processes remain full SQLite clients. Their commits publish the same shared capture predicates, and the capture host reads the resulting WAL state. They do not create another controller participant or another DBH history.

Capture ownership is per database rather than per process. One process can host capture for database A while acting as an ordinary client of database B.

Presence covers every activity that can touch SQLite

A second shared memory lock carries shared presence leases. Each user connection, open in progress, and independent internal task holds its own lease before it enters SQLite and until it can no longer hold SQLite locks or publish work.

Presence acquisition is also a validation point. Before opening SQLite, the process confirms that the shared memory session, capture-host identity, and authority state still match. Recovery and terminal shutdown take presence exclusively, which proves that no application process can retain usable database state while raw bytes are inspected or final state is committed.

A client-only process simply releases its own presence when it closes. It does not become the terminal coordinator because its last local connection ended.

Capture ownership survives process exit, not machine loss

The operating system releases the capture-host lease when the owning process’s final descriptor closes, including after a crash. A surviving application process can then acquire the lease and adopt the same-boot state already published in the shared memory.

The successor validates the database identity and controller record, loads the published ring edge, checks the complete ring tail, reconciles the WAL/WAL2 requested and completed frontiers, and resumes DBH from its checksummed prefix. It recreates process-local threads and network connections, but does not discard valid ring or DBH progress merely because their original process exited.

This is a same-host, same-boot handoff. The ring and active DBH prefix are not the machine-crash durability layer. After a reboot or complete host loss, recovery depends on the synced SQLite and WAL state, finalized DBH and catalog records, replicas, and object storage.

Any malformed ring tail, incompatible WAL evidence, or gap between the published frontiers leaves access fenced for recovery.

Mutable settings do not block attachment. Existing processes follow the active owner’s shared capture, codec, integrity, and latency policy. Each process keeps its latest successfully normalized settings as the desired configuration for a future owner generation. A ring-capacity request takes effect only when the shared-memory file is recreated with no live mappings.

Local ownership cannot extend primary authority

Acquiring the capture-host lease identifies the process that runs local services; it does not grant writes. A same-node successor may preserve an existing primary grant only when the shared controller identity and token still match and the absolute grant deadline has not expired.

Every other case closes writer admission before reconnecting to the controller. No shared memory lock, process takeover, or local database state can mint a fencing token or extend its deadline.

Capture-loss recovery covers the last-process exit

A supervised sqlstyle run --config FILE --database NAME entry with capture: "off" and on_capture_loss: "recover" is recovery-only. While an application process owns capture, it waits without taking ordinary capture ownership. If that owner exits and no application process remains to finish shutdown, one recovery process acquires exclusive terminal presence.

The recovery process keeps application admission fenced, validates the ring, WAL, DBH, catalog, and authority evidence, and continues the interrupted local shutdown or recovery. It may establish the required replica, object-storage, or successor coverage before releasing authority, but it never exposes a writer-facing runtime or gains authority from local lock ownership.

Integrity modes describes the clean-state and external coverage transition the companion completes. Primary authority and failover distinguishes this local process handoff from a change of primary node.