Transactions and concurrency
Transactions and correctness
Each updating statement is atomic: it succeeds as a whole or rolls back. Use an explicit driver transaction when several statements must commit together.
import os
from galactus import Driver
with Driver("bolt://127.0.0.1:7687", "gdb", os.environ["GDB_PASSWORD"]) as driver:
driver.begin()
driver.execute_query("CREATE (:Account {id: $id})", {"id": 1})
driver.execute_query("CREATE (:Account {id: $id})", {"id": 2})
driver.commit()
Install the Python driver and set GDB_PASSWORD
in the application environment to the configured server password. An omitted
database uses the server's configured default. Call driver.rollback() to abandon
an open transaction deliberately. The context manager closes the connection if
the block exits early; a database or transport failure discards the connection.
Do not reuse that connection or call rollback after it has been discarded.
The 0.1 drivers do not replay failed writes. If the connection is lost during COMMIT, the outcome can be unknown; check application state before retrying.
An explicit rollback or a dropped connection rolls back an open transaction. A transaction sees its own writes. Existence and node-key constraints are validated at the commit boundary. The durability setting determines when a successful commit is acknowledged; see durability.
Read and write concurrency
Read statements can run concurrently. A write statement or an open write transaction has exclusive access to its database, so readers and other writers wait for it to finish. Keep write transactions short.
Read-mode sessions can overlap, but do not capture a repeatable-read snapshot
when a transaction starts. Later statements can see newly committed changes.
Large scans and projections can use additional read workers controlled by
GDB_QUERY_THREADS.
Group durability lets another writer execute while an earlier commit waits for
disk sync. With GDB_READ_AFTER_DURABLE=true, readers wait for a pending sync
before reading. A reader can still receive its response before the writing
client receives its acknowledgement.
Different databases have separate locks and storage streams, so work on one database need not block another. Only one server process may use a durable directory at a time; give each instance its own volume.
Storage errors
An indeterminate append or sync failure, or detected storage corruption, makes the affected database refuse further work until it is reopened and recovery checks complete. Inspect the logs and storage before restarting; do not treat this as an ordinary query error or retry writes blindly.