GraphBatch close() restores default WAL flush instead of the configured value: durability silently downgraded after any bulk load (txWalFlush=2 -> async, 79 -> 4,120 tx/s)

[tae898]

Summary

GraphBatch temporarily relaxes the WAL flush policy for bulk speed (documented, sensible) — but on close() it restores the engine default rather than the value the user configured. After any GraphBatch bulk load, every subsequent transaction on that database silently stops honoring arcadedb.txWalFlush=2 (fsync-per-commit): the durability contract is downgraded with no error, log line, or signal.

Reproduction (embedded, 26.8.1.dev2 line; measured on idle i9-12900HK, NVMe)

// JVM started with -Darcadedb.txWalFlush=2 (YES_FULL)
// 1) per-commit inserts BEFORE any GraphBatch:
//      ~79 tx/s   <- fsync honored (disk floor)
// 2) run any GraphBatch bulk load (500 vertices is enough), close it
// 3) same per-commit inserts AFTER:
//      ~4,120 tx/s <- fsync silently gone

Python-bindings script that shows exactly this (same engine calls) available on request; the effect reproduces deterministically. The pre/post asymmetry isolates it to GraphBatch's save/restore of WAL settings ("Saved state for restore after close" block): it appears to restore a captured-too-late or default value instead of the configured one.

Why it matters

Any application that (a) sets full durability and (b) ever bulk-loads via GraphBatch runs the rest of its life at relaxed durability without knowing. We found it while building a matched-durability benchmark ablation: graph cells (bulk-loaded via GraphBatch) refused to show fsync-bound throughput while document cells (plain INSERT ingest) behaved correctly — the discrepancy only made sense once the post-GraphBatch downgrade was isolated.

Suggested fix

Capture the configured value (GlobalConfiguration or database-level override) before relaxing, and restore exactly that on close(), including on exceptional exit; a log line on relax/restore would also make the temporary window visible.

[lvca]

Confirmed and fixed on main (commit daf84c8), it will be in the next release.

The problem was slightly worse than reported: GraphBatch never restored the WAL settings at all on close(). And because the transaction settings live on a per-thread object that is reused by the following transactions, the relaxed policy stayed in place for the rest of the thread's life, so every later commit ran without the fsync you asked for.

The fix captures the WAL settings that were actually in effect when the batch was created (your configured arcadedb.txWalFlush / arcadedb.txWAL, or any override you set via Database.setWALFlush()) and puts exactly those back on close(), including when the batch closes with an error. We deliberately did not re-read the global configuration on close, since that would silently discard an application-level override.

There is now also a log line when the batch relaxes durability, so the temporary window is visible.

Regression test: GraphBatchWALRestoreTest.

Thanks for the very precise report, the before/after measurement made it easy to pinpoint.

---

❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.

[tae898]

Verified on current main (26.8.1.dev4): the same graph benchmark that exposed the leak now shows exactly the expected full-durability behavior after a GraphBatch bulk load — mixed OLTP (15% writes) at ~590 ops/s with txWalFlush=2 (vs ~4,300 when the leak silently dropped the policy), and the isolated before/after-GraphBatch probe no longer diverges. The relax/restore log line is a nice touch for operators. Thanks for the fast fix — and for catching that it was worse (thread-lifetime leak) than we reported.