Transaction Isolation and Consistency

Transaction Isolation in Twisp

In systems that demand correctness and high concurrency, transaction isolation plays a critical role in ensuring consistency and preventing anomalies. Twisp leverages an ACID Multi-Version Concurrency Control (MVCC) transaction layer to implement robust isolation levels tailored to the needs of ledger systems.

Twisp's MVCC provides:

• Interactive transactions: Supports all-or-nothing semantics for transactions, ensuring atomicity and isolation.
• Snapshot Isolation: Transactions operate on a consistent and isolated view of data, ensuring transactions operate on immutable data snapshots.
• Anomaly prevention: Guarantees that transactional operations produce fully consistent results without partial or invalid reads along with write skew prevention.
• Strong consistency: Committed records and balances are readable in a strongly consistent manner through reads by ID, lookups by unique key, and most indexes, with no anomalies or partial updates. A few listing indexes are eventually consistent; see Eventually Consistent Listings.

Isolation Levels Overview

Twisp supports four distinct transaction isolation levels, balancing between performance and correctness:

1. Read Committed:

   • Ensures that the most recently committed data is visible to a transaction.
   • Use cases: Workflows requiring real-time, consistent reads that can tolerate a non-snapshot view of data.

2. Snapshot Isolation (System Default):

   • Guarantees that transactions operate on a point-in-time consistent snapshot of the data.
   • Use cases: Workflows requiring strong correctness without paying a performance penalty.

3. Repeatable Read:

   • Guarantees that read data has not changed on transaction commit providing read stability.
   • Use cases: High-consistency workflows for complex, interactive, multi-row updates.

4. Serializable:

   • In addition to read stability, also provides phantom avoidance that ensures scans would not return additional data on transaction commit.
   • Use cases: Workflows where absolute correctness outweighs performance concerns.

Preventing Transaction Anomalies

In high-concurrency environments, transaction anomalies can corrupt data or lead to business-critical errors. Twisp's isolation levels guard against common database anomalies. The following anomalies are thoroughly tested in every build via our conformance test suites:

• G0: Write Cycles (dirty writes)
• G1a: Aborted Reads (dirty reads, cascaded aborts)
• G1b: Intermediate Reads (dirty reads)
• G1c: Circular Information Flow (dirty reads)
• OTV: Observed Transaction Vanishes
• PMP: Predicate-Many-Preceders
• P4: Lost Update
• G-single: Single Anti-dependency Cycles (read skew)
• G2-item: Item Anti-dependency Cycles (write skew on disjoint read)
• G2: Anti-Dependency Cycles (write skew on predicate read)

By addressing these anomalies, Twisp's isolation levels ensure correctness and make ledger operations easy to reason about, even under high concurrency.

Strong Consistency

Twisp ensures strong consistency for reads by ID, lookups by unique key, and every index that is written in the same transaction as its record, guaranteeing that every transaction reflects an accurate state of the ledger. These reads see your own writes, including earlier writes in the same transaction, with no stale or partial results.

Eventually Consistent Listings

Some listings read from asynchronous indexes, which Twisp updates after the write commits. Examples are accounts by NAME, STATUS, or CODE without an eq filter, AccountSet.members, and the actions and executions lists. The Built-In Async Indexes table lists them all. Through these listings:

• A record that was just created or changed can be missing for a short time after the write commits, usually under a second.
• Within one transaction, records the same transaction wrote are not included. This holds for every operation in one GraphQL request, a tool call, and an MCP program program.

To read a record you just wrote, read it by ID, such as account(id:), or by a unique key, such as accounts(index: {name: CODE}, where: {code: {eq: "..."}}).

Balance Calculations

For high-volume, concurrent entry posting to concurrent-enabled accounts or aggregates, Twisp implements a non-blocking, transactionally consistent, and deterministic balance update process. The following balance types are provided to allow context-specific balance retrieval consistency without compromising correctness.