Cluster Transactions

DistributedTransactionsMVCC

Beta Works · surface still evolving · Snapshot visibility, conflicts, the reaper and boot recovery are proven across two workers. Cross-stage snapshots for UPDATE are recorded as a limitation below.

★

Premium feature Available only with a license key that grants cluster. Flags and environment variables cannot enable it. To license this feature, contact the AetheriusDB team at aetheriusdb.com or aetheriuslabs.com. See Licensing → Premium features.

What you get

In cluster mode a transaction behaves the way you expect from a single node:

• BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO and RELEASE are accepted, and a statement outside a transaction autocommits.
• A reader sees only committed data. Rows written by a transaction that is still open, or that was rolled back, are invisible to every other connection, on every worker, with no waiting.
• A rollback is instant however many rows the transaction wrote. Nothing is undone or replayed; the rows simply never become visible and are removed later by the vacuum.

Write conflicts

Two transactions that try to delete or update the same row do not wait for each other. The second one fails immediately with SQLSTATE 40001 (serialization failure), its transaction is aborted, and the message names the transaction holding the row. Retry the transaction; the first writer’s commit or rollback resolves the row either way.

ERROR 40001: write-write conflict: a row is held by in-flight transaction 91;
this transaction was aborted, retry it

Stalled transactions are reaped

A transaction that stays open too long is aborted automatically:

AETHERIUS_TX_TIMEOUT=5000   # milliseconds, the default

The watchdog runs in the background and also whenever the cluster is at its in-flight limit. A reaped transaction’s writes are discarded exactly as if it had rolled back; the client’s next statement on that transaction fails.

At most 64 transactions may be in flight at one orchestrator. A BEGIN beyond that first reaps any stalled transaction and, if all 64 are genuinely live, is refused.

Aborted work is cleaned up

Rows and containers written by a transaction that was rolled back or reaped are never returned, and the worker’s vacuum removes them from disk on its next sweep without being asked. A deletion made by an aborted transaction is cancelled the same way — the row comes back.

Restarting the orchestrator

The orchestrator keeps no transaction log. When it boots, it asks every worker where the cluster’s transaction numbering stands and continues safely above the highest answer. If a worker cannot be reached it keeps asking until the boot deadline rather than guessing — a guess could reuse a number a worker has already seen.

Limits in this release

• An UPDATE runs as a delete of the old rows followed by an insert of the new ones; a concurrent reader between the two stages may see neither version of the affected rows.
• SET inside a transaction, SHOW, EXPLAIN, SELECT without a FROM and the system.* views run on the orchestrator locally; DDL is refused in cluster mode.
• The 64-transaction window and the timeout are per orchestrator.

Transaction Isolation →

The single-node transaction model.

Deletes, Updates & the Vacuum →

Where rolled-back rows go.

Multi-Tenancy →

Every transaction belongs to one tenant.