Drivers, Sessions, Transactions

Drivers, Sessions, Transactions

Sessions are cheap, transactions cost — and managed transactions retry on transient errors.

Why it matters

The driver gives you sessions (per-thread) and transactions (per-unit-of-work). Read transactions can be routed to followers; write transactions go to the leader.

Going deeper

The driver layers three things:

• Session — a lightweight, per-thread context that also carries causal bookmarks. Cheap to open; don't share one across threads.
• Transaction — the unit of work. Reads can route to followers; writes go to the leader.
• Managed (transaction-function) transactions — session.execute_write(fn) / execute_read(fn) — automatically retry on transient errors (deadlock, leader re-election) with backoff.

def add_order(tx, cust_id, total):
    tx.run('MATCH (c:Customer {id:$id}) '
           'CREATE (c)-[:PLACED]->(:Order {total:$t})', id=cust_id, t=total)

with driver.session() as s:
    s.execute_write(add_order, 'c1', 42.0)

Prefer managed transactions for almost everything: the retry logic is exactly the resilience you'd otherwise hand-roll, and they keep the read/write routing correct.

Sessions and transactions are a phone line and a single call. Opening a line (session) is cheap; what costs is the call itself (transaction). A managed transaction is calling through an operator who, if the line drops mid-sentence (deadlock, leader switch), quietly redials and reconnects you — instead of you getting a dial tone and an error.

• Explicit BEGIN/COMMIT everywhere. No automatic retry on transient errors. Fix: use managed execute_write/execute_read.
• Sharing a session across threads. Sessions aren't thread-safe. Fix: one session per unit of work/thread.
• Non-idempotent write functions. A retried transaction runs twice. Fix: make the function idempotent (MERGE, not blind CREATE).