ArcadeDB defaults arcadedb.txWalFlush to 0 (no fsync). This is the same class of issue the blog post describes. The key facts:
┌─────────────┬──────────────────────┬───────────────────────────────────────┐
│ Setting │ Meaning │ Power-loss safe? │
├─────────────┼──────────────────────┼───────────────────────────────────────┤
│ 0 (default) │ No channel.force() │ No - WAL in OS page cache can be lost │
├─────────────┼──────────────────────┼───────────────────────────────────────┤
│ 1 │ channel.force(false) │ Yes - data fsynced, metadata may lag │
├─────────────┼──────────────────────┼───────────────────────────────────────┤
│ 2 │ channel.force(true) │ Yes - full fsync including metadata │
└─────────────┴──────────────────────┴───────────────────────────────────────┘
The default is fine for development/testing but risky for production. Unlike SurrealDB though, ArcadeDB does have proper WAL-based recovery, so normal crashes (process kill, OOM) are safe since the OS page cache survives. The risk is only power loss / kernel panic.
Furthermore, ArcadeDB allows to change this behavior ->
Per-database:
database.setWALFlush(WALFile.FlushType.YES_FULL);
Per-transaction:
database.getTransaction().setWALFlush(WALFile.FlushType.YES_FULL);
Per async executor:
database.async().setTransactionSync(WALFile.FlushType.YES_NOMETADATA);
Via configuration (per database, since scope is SCOPE.DATABASE):
database.getConfiguration().setValue(GlobalConfiguration.TX_WAL_FLUSH, 2);
Skipping fsync for each write is fine in development and test. In production the base should be 1, at least.
ArcadeDB defaults
arcadedb.txWalFlushto 0 (no fsync). This is the same class of issue the blog post describes. The key facts:The default is fine for development/testing but risky for production. Unlike SurrealDB though, ArcadeDB does have proper WAL-based recovery, so normal crashes (process kill, OOM) are safe since the OS page cache survives. The risk is only power loss / kernel panic.
Furthermore, ArcadeDB allows to change this behavior ->
Per-database:
Per-transaction:
Per async executor:
Via configuration (per database, since scope is SCOPE.DATABASE):
Skipping fsync for each write is fine in development and test. In production the base should be 1, at least.