What is ACID?
ACID defines the properties of a transactional database. The four parts are:
A: Atomicity. Either all operations in a transaction succeed, or none are applied.
C: Consistency. The database only moves from a correct state to a correct state when a transaction is committed.
I: Isolation. Concurrent transactions operate as if they were run sequentially.
D: Durability. Data is not lost or corrupted in the event of hardware or power failure.
For more detail please read ACID.
This page addresses TypeDB’s transactionality.
TypeDB delivers ACID guarantees up to a slightly relaxed form of isolation known as Snapshot Isolation.
Note that consistency guarantees where implemented in version 2.1.0 (the first TypeDB version).
TypeDB transactions operate under a snapshot model. If an error occurs in the transaction, none of the operations will be applied to the persisted data. If a commit succeeds, all the changes are guaranteed to be immediately visible to following transactions.
As of version 2.1, the server will throw errors during commit if the transaction would violate consistency guarantees. There are two primary types of data-level conflicts which could violate consistency:
modify-delete: a transaction extends or adds to a concept that a concurrent transaction deletes
key: a transaction adds a key-ownership (which must be unique) at the same time as another transaction.
In both cases, one transaction will be picked to successfully commit, and the other will be rejected. It is common to build a re-try mechanism when loading data that relies on key conflicts to load data in parallel.
Like many established databases, we relax the “full” isolation guarantee (called
When a transaction is opened, the database is snapshotted and no further changes from other transactions will be visible until a new transaction is opened.
After commit, all of the changes from the transaction are immediately visible to new transactions.
This mode of isolation guarantees that transactions that operate concurrently, on overlapping snapshots of the database, will conflict and fail at commit time if they were to lead to consistency violations.
Durability is guaranteed with the use of a write-ahead-log at the storage layer. This means under crashes or power failures, all data that finished committing will be available on reboot.
Note that un-recoverable failures like corrupt drives or physical damage are not considered as part of durability guarantees.