Transaction

In one line: the unit of isolation — one writer, one consistent read snapshot, one atomic set of changes that either all commit or all roll back.

A Transaction is owned by the thread that created it (single-thread-affine) and carries no locks on itself — that is what makes opening one essentially free. Its reads run against a snapshot fixed at creation; its writes become visible to later readers only at Commit, and are discarded on Rollback.

A transaction is a true ACID envelope only for the Versioned data it touches. For SingleVersion/Transient components it still gives you thread affinity, atomic entity spawn/destroy, and a consistent snapshot of any Versioned components in the same archetype — but not isolation, rollback, or commit-timed durability on those components' values.

⚠️ Commit() returning makes a change visible, not necessarily durable — that is the Unit of Work's job. See visible ≠ durable.

How it relates

• Unit of Work — wraps transactions; decides when their commits become crash-safe.
• Snapshot isolation — what a transaction's reads see; its snapshot is fixed at creation.
• Storage mode — determines what "transactional" actually guarantees per component.
• Durability — mode & discipline — decide when and how a committed transaction reaches disk.
• Conflict resolution — what happens at Commit when another writer changed the same entity.
• Deadlines & timeouts — every transaction runs under a deadline; waits fail as typed timeouts.

In the API

• Transaction — the type itself.
• DatabaseEngine — CreateQuickTransaction / CreateReadOnlyTransaction, or CreateUnitOfWork(...).CreateTransaction(...).
• EntityRef — Read<T> / Write<T> on an opened entity.

Learn & use

• Narrative: Guide ch.3 — Transactions & durability
• Reference: Isolation & durability cheat sheet
• Feature detail: Transactions feature catalog · creation patterns