Atomicity
- Each transaction is treated as a single unit whether it fails or succeeds
- The entire transaction is rolled back if any part of it fails
- This guarantee prevents partial updates of the database
Consistency
- Ensures that each transaction obeys all the constraints and rules of the table/database once committed
Isolation
- Transactions are generally concurrent on a database
- Isolation ensures that concurrent executions of transactions don’t alter the state of the database differently than if those transactions occurred sequentially
Some transaction race conditions can be eliminated using different isolation levels:
- Read Committed Isolation: Prevents dirty reads
- Repeatable Read Isolation: Prevents dirty reads and non-repeatable reads
- Serialisable: Highest isolation - places a lock on the query dataset until the transaction is complete
The serialisable isolation is able to prevent:
- [Dirty reads](slipbox/2502081555#Dirty Read)
- [Non-repeatble reads](slipbox/2502081555#Non-Repeatble Read)
- [Phantom Reads](slipbox/2502081555#Phantom Read)
Durability
- Guarantees that once a transaction is committed, it will remain committed even after system failure
- Usually done using Write Ahead Logging which persists the changes to the disk before confirming the commit
- This may also include replicating data across other nodes in distributed databases