Database System Concepts" 18 - Transactions

A transaction is a unit of program execution that accesses and possibly updates different data items. Transactions are critical to implementing data updates in the database, so that concurrent execution and various failures will not result in an inconsistent state of the database.

1. Transactions have ACID properties: atomicity, consistency, isolation, and durability.
Atomicity ensures that all the effects of a transaction are either fully reflected in the database, or not reflected at all. The database cannot be in a state after a transaction has been partially executed after a failure.
Consistency Guarantee If the database is consistent from the beginning, the database is still in a consistent state after the transaction is executed.
Isolation ensures that concurrently executing transactions are isolated from each other, so that each transaction does not feel the concurrent execution of other transactions in the system.
Durability guarantees that once a transaction commits, its changes to the database are not lost, even if the system fails.

Second, the concurrent execution of the transaction improves the throughput and system utilization of the transaction, and also reduces the waiting time of the transaction.
However, when multiple transactions are executed concurrently in the database, data consistency may no longer be guaranteed. Therefore, the system must control the interaction between concurrent transactions.
Since transactions are the unit of consistency, serial execution of transactions guarantees consistency. Serial schedules are serializable, but if the steps of many transactions are executed interleaved, it can be difficult to determine whether a schedule is serializable. Determining what operations a transaction has and how the operations of multiple transactions interact can be difficult. Therefore, all the details of a transaction on a data item are usually not considered, but only two operations: read and write.
A system that guarantees this property is said to be guaranteed serializability by requiring that any schedule resulting from concurrent execution of a set of transactions has the effect of being executed equivalently to the effect of executing those transactions in some serial order. Considering that a schedule S contains two instructions, I and J, only when I and J are all read instructions, the execution order of the two instructions is irrelevant, and as long as at least one of them is a write instruction, I and J are in conflict. .
If a schedule S can be transformed into S1 through a series of non-conflicting instruction exchanges, then S1 is said to be the conflicting equivalent of S. There are several different equivalent concepts, so serializability is divided into conflict serializability and view serializability.

3. The serializability of schedules generated by concurrent execution of transactions can be guaranteed by one of several concurrency control mechanisms. Given a schedule, it can be determined whether it is conflict serializable by constructing a priority graph for the schedule and searching for whether it is acyclic. There are also better concurrency control mechanisms available to guarantee serializability.
The schedule must be recoverable so that if transaction a depends on transaction b, if b aborts, a also aborts. The schedule is also preferably cascade-free, so that the abort of one transaction does not cause the cascading abort of other transactions. No cascading is guaranteed by only allowing transactions to read committed data.

Learning materials: Database System Concepts, by Abraham Silberschatz, Henry F.Korth, S.Sudarshan