memory-write-ahead-vfs 0.2.0

Highlights

• Adds safe deferred read-to-write transaction upgrades and stale-snapshot rejection.
• Supports serialized shared attached-database transactions and fail-closed quarantine when a rollback-journal owner terminates mid-transaction.
• Adds immediate terminated-worker handle recovery and expanded capacity, lock, write, and checkpoint diagnostics.
• Publishes a reproducible PowerSync MemoryVFS comparison with three worker configurations and 1–4 total MWA connections.
• Adds CI, package-content validation, third-party provenance, and a wa-sqlite >=1.7.0 <1.8.0 peer constraint.

Public benchmark

In the both-workers run, the 3-connection Memory Write-Ahead VFS pool recorded, relative to PowerSync MemoryVFS with one connection:

• 49.0% lower median concurrent-read latency
• 47.6% lower median mixed-read latency
• 75.2% lower median mixed-workload write-completion latency
• effectively identical median sequential latency (-0.2%)

The benchmark compares complete implementation stacks. Each result records worker placement, total connections, sample counts, correctness checks, dependency versions, and aggregate page-cache ceilings. RSS was not measured, so the 3-connection recommendation is throughput-focused rather than memory-balanced.

See the methodology and formatted results and machine-readable artifacts.

Validation

• 27 browser integration tests
• 540/540 stress iterations
• three complete benchmark configurations
• format, TypeScript, build, benchmark sanitizer, production audit, package contents, and fresh consumer import

v0.1.2

Fixes

• Reject duplicate primary opens while the first open is pending. A second open of the primary database arriving before the first open's #retryOpen settled used to queue another #retryOpen on the same file object; the racing retries overwrote file.accessHandle/waHandles, permanently leaking the losing handle set's runtime open-handle counts (unreclaimable, since the leaking owner is alive) and racing two WAL replays over the same shared buffers. An existing unopened primary file with retryResult === null can only mean an open in flight, so jOpen now rejects the duplicate with SQLITE_CANTOPEN before anything is allocated.

Testing

• New browser regression test drives jOpen directly through the pending window and verifies the duplicate is rejected and openHandleCount returns to 0 after closing the surviving connection.
• Published after the full verification gate: prettier check, typecheck, 21 Playwright browser tests, build.

Install

npm install memory-write-ahead-vfs@0.1.2

v0.1.1

Fixes

Owner lease claiming no longer defers recovery of dead owners' slots. claimOwnerLeaseSlot's stale-leftover reclaim never checked ownerId, so a claim scan walking past a dead owner's slot published a fresh heartbeat before its CAS lost. Every scan pushed recoverAbandonedRuntimeOwnerLeases back by a full stale window, could abort in-flight recoveries, and could wedge resetRuntime behind handles that no longer existed. Claiming now skips owned slots entirely — live, dead, or mid-recovery — so stale heartbeats keep aging into recovery.

Lease exhaustion self-heals. When every slot is taken, ensureLocalRuntimeLease now reclaims abandoned leases and retries once before throwing, so a runtime full of dead owners recovers at open time instead of failing with "owner lease capacity exhausted" until reset.

Both behaviors are covered by new browser regression tests (stale dead-owner slot left untouched; full-exhaustion recovery), each observed failing before the fix.

Verification

Published through the prepublishOnly gate: Prettier check, strict typecheck, 20 Playwright browser tests (Chromium, cross-origin isolated), build.

Install

pnpm add memory-write-ahead-vfs @journeyapps/wa-sqlite

v0.1.0

First public release of memory-write-ahead-vfs — a SharedArrayBuffer-backed in-memory write-ahead VFS for @journeyapps/wa-sqlite.

Highlights

• One shared, named in-memory SQLite runtime that structured-clones into dedicated workers — every worker runs its own SQLite WASM instance against a single copy of the database bytes.
• Segmented, growable SharedArrayBuffer storage: start small, grow in place up to the configured ceiling, no re-sharing or copying.
• Cross-worker file locks built on Atomics with heartbeat-based stale-lock recovery: dead workers' locks and lease slots are reclaimed safely (CAS-guarded claim/release/recovery protocol).
• Snapshot isolation, rollback, and checkpointing delegated to wa-sqlite's WriteAhead helper.
• Capacity limits enforced with clear errors; diagnostics expose file sizes, segment counts, lock state, and recovery counters.

Verification

Released through the prepublishOnly gate: Prettier check, strict TypeScript, 18 Playwright browser integration tests (WAL round-trips, multi-worker concurrency, dead-worker lock and lease recovery, capacity exhaustion, sequential reopen), and a clean build.

Install

pnpm add memory-write-ahead-vfs @journeyapps/wa-sqlite

Requires a cross-origin-isolated browser context with growable SharedArrayBuffer support. See the README for the worker usage example and the locking model.