A transaction is a program execution unit that accesses and possibly updates different data items. Transactions are critical to implementing data updates in a database, so that concurrent execution and various failures do not cause the database to be in an inconsistent state.
First, the business has acid characteristics: atomicity, consistency, isolation and durability
Atomicity guarantees that all the effects of a transaction are either reflected in the database or not at all. After a failure, the database cannot be in the state after the thing has been partially executed.
Consistency guarantee if the database is consistent at first, the database is still in a consistent state after the transaction executes.
Isolation guarantees that concurrently executed transactions are isolated from each other, so that each transaction does not feel the concurrent execution of other transactions in the system.
Durability guarantee Once a transaction commits, its changes to the database are not lost, even if the system may fail.
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. The system must therefore control the interactions between the concurrent transactions.
Because transactions are units of consistency, serial execution of transactions guarantees consistency. Serial scheduling is serializable, but if the steps of many transactions are interleaved, it is difficult to determine whether a schedule is serializable. It is difficult to determine what the operations of a transaction are and how the operations of multiple transactions interact. Therefore, you typically do not consider all the details of a transaction on a data item, but consider only two operations: Read and write.
The execution effect of any schedule that requires concurrent execution of a transaction set is equivalent to the effect performed by these transactions in a sequential order, and the system that guarantees this feature is called guaranteed serializable. Consider a dispatch s containing i,j two instructions, only I and J are all read instructions, the execution order of two instructions is insignificant, and as long as there is at least one write instruction, I and J are conflicting.
If the dispatch s can be converted into S1 through a series of non-conflicting instruction exchanges, then the S1 is called the conflict equivalence of S. There are several different equivalence concepts, so serializable can be divided into conflicting serializable and view serializable.
Thirdly, the serialization of scheduling generated by transaction concurrency can be ensured by a variety of concurrency control mechanisms. Given a schedule, it is possible to determine whether a conflict can be serialized by constructing a priority graph for the schedule and whether the search is not a loop. There is also a better concurrency control mechanism that can be used to ensure serialization.
The schedule must be recoverable, so that if transaction a relies on transaction B, if B is aborted, A is also aborted. Scheduling is also best to be cascade-free, so that it does not cause cascading aborts for other transactions due to the abort of one transaction. No cascading is guaranteed by allowing only transactions to read data that has already been committed.
Learning materials: Database System concepts, by Abraham Silberschatz, Henry F.korth, S.sudarshan
Database System Concepts 18-transactions