ACID guarantees
All TypeDB transactions have ACID guarantees.
Schema operations have additional concurrency restrictions to guarantee schema integrity. See the Schema integrity enforcement section.
Atomicity
TypeDB transactions are all or nothing. If a commit succeeds, all of its changes are persisted. If it fails, all of its changes will be rolled back.
Consistency
TypeDB validates all changes to data and schemas. If changes to a database violate schema or data constraints, the transaction will fail and be rolled back.
Isolation
TypeDB transactions use snapshot isolation and optimistic concurrency control to support simultaneous, lock-free read/write transactions. Thus, a transaction operates on its snapshot of the data, independent of any other. All of its changes are hidden from other transactions. However, they will become visible immediately after a successful commit.
If two transactions attempt to modify the same data, one will succeed on commit while the other will fail. However, one transaction can read data while another is writing it.
Durability
TypeDB writes transactions to a write-ahead log upon a commit, ensuring they can be recovered if an unexpected failure, e.g., power outage, occurs before the data is modified.
|
TypeDB durability guarantees do not apply when storage devices become corrupt or damaged. |
Successful write transactions are written to the write-ahead log before returning a response to the client. If a transaction is not successful, all changes are rolled back.
For TypeDB Cloud and TypeDB Cloud installations, transaction acknowledgment is sent to the client after a majority of replicas replicated the transaction results.
Schema integrity enforcement
The following limitations apply for every database to protect its schema integrity:
-
Only one Schema session can be opened.
-
Only one Write transaction in a Schema session can be opened.
-
Opening a Schema session prevents any Data Write transactions.
-
Any Write transaction opened in a Data session prevents us from opening a Schema session.
|
If anything prevents us from opening a session, TypeDB will wait for a timeout of about 10 seconds and, if the problem persists, throw an error: [SSN03] Invalid Session Operation: Could not acquire lock for schema session. Another schema session may have been left open. |
Hence, we can always:
-
open Data session,
-
open a Read transaction in an existing session of any type.