Understanding Transactions-atomicity, consistency, isolation, and persistence

A transaction is a set of operations performed on a system, in order to ensure the integrity of the system, the transaction needs to have acid characteristics, as follows:
1. atomicity (Atomic)
A transaction contains multiple operations, which either execute all or do not. To implement the atomicity of a transaction, to support a rollback operation that, after an operation fails, rolls back to the state before the transaction executes.
Rollback is actually a high-level abstraction, and most DB implements transactions in a data snapshot of a transactional operation (for example, MVCC), does not modify the actual data, and if the error is not committed, it is natural to support rollback.
In other systems that support simple transactions, they are not updated on the snapshot, and the actual data is manipulated directly. You can rehearse all the actions you want to perform, and if you fail, these operations will not be executed, which is a simple way to achieve atomicity.
2. Consistency (consistency)
Consistency refers to a transaction that transitions a system from one consistent state to another consistent state. The consistency of transactions determines the complexity of a system's design and implementation. Transactions can be of varying degrees of consistency:
Strong Consistency: The read operation can read immediately to the submitted update operation.
Weak consistency: A committed update operation is not necessarily read immediately by the read operation, and there is an inconsistency window that refers to a time when the read operation can read to the latest value.
Final Consistency: is a special case of weak consistency. The transaction updates a copy of the data, and eventually the consistency guarantees that the same value is updated in the absence of other transactions, and eventually all transactions are read to the latest value of the previous transaction update. If no error occurs, the size of the inconsistency window depends on: Communication delay, system load, and so on.
Other consistency variants include:
monotonic Consistency: If a process has read a value, subsequent values will not be read earlier.
Session Consistency: During a session that guarantees client-server interaction, read operations can read the latest values after the update operation.
3. Isolation (Isolation)
The degree to which concurrent transactions affect each other, such as whether a transaction will read to another uncommitted transaction modified data. Problems that can occur when a transactional concurrency operation are:
Dirty Read: Transaction a modifies a data but is not committed, and transaction B reads the result of an uncommitted update to transaction A, and if transaction a commits fails, transaction B reads dirty data.
non-repeatable read: In the same transaction, the results read to the same data are inconsistent. For example, the result that transaction B reads before transaction A is submitted may be different from the results read after the commit. Non-repeatable reads occur because transactions are concurrently modifying records, to avoid this situation, the simplest way is to lock the records to be modified, which leads to increased lock competition, affecting performance. Another approach is to avoid non-repeatable reads with MVCC without locking.
Phantom Reading: In the same transaction, the same query returned multiple times with inconsistent results. Transaction A adds a new record, and transaction B performs a query operation before and after transaction a commits, discovering that one more record than the previous one. Phantom reads are caused by the increased recording of concurrent transactions, which cannot be resolved by record locking as non-repeatable reads because new records cannot be locked at all. You need to serialize the transaction to avoid Phantom reads.
The isolation level of a transaction is from low to High:
Read Uncommitted: The lowest isolation level, nothing needs to be done, one transaction can read the results of another transaction uncommitted. All concurrent transaction problems can occur.
Read Committed: The result of the update will be seen by other transactions only after the transaction commits. Can solve the dirty read problem.
repeated Read: In a transaction, the read result for the same data is always the same, regardless of whether there are other transactions that manipulate the data, and whether the transaction is committed. Can resolve dirty read, non-repeatable read.
Serialization: Transaction serialization execution, the highest isolation level, sacrificing the concurrency of the system. All problems with concurrent transactions can be resolved.
Often, in engineering practice, isolation is compromised in the interest of performance considerations.
4. Persistence (Durability)
After a transaction is committed, the effect on the system is permanent.