Importance of Serialization in Transactional Data
Importance of Serialization in Transactional Data
12 August 2020
Ideally, transactions should be serializable. Transactions are said to be serializable if the results of running transactions simultaneously are the same as the result of running them serially i.e., running them one after the other. It is not important which executes first(unless there is a dependency on the processes), only that the result doesn’t reflect any mixing of the transactions.
So why is serializable desirable? In other words, why is it important that one transaction should be completed before starting another transaction? Consider the following problem, A salesman is entering new orders at the same time when the clerk is sending out bills. Let’s assume the salesman enters an order from company X but doesn’t commit it; the salesman is still talking to the representative from company X. The clerk requests a list of open orders and discovers the order for company X and sends them a bill. Now the company representative decides to change the order, so the salesman changes the order before committing the transaction, as a result of this the company X gets an incorrect bill.
Suppose the transactions for salesman and clerk were serializable, this problem would never have occurred. Either the salesman’s would have finished before the clerk’s transaction started, in which the clerk would have sent the correct generated bill, the clerk’s transaction would have finished before the salesman’s transaction started, in which case the clerk wouldn’t have sent the bill to company X.
By definition of serializability, it ensures that a schedule for executing concurrent transactions is equivalent to one that executes the transactions serially or in some particular order. Serializability assumes that all accesses to the database are done using read and write operations. A serializable schedule is called correct if we can find a serial schedule that is equivalent to it. Given a set of transactions T1, T2, T3,…….Tn. For given schedules S1 and S2 of these transactions are equivalent if the following conditions are satisfied:
- Read-Write Synchronization: If a transaction reads a value written by other transactions in one schedule, then it also does so in the other schedule.
- Write- Write Synchronization: If a transaction overwrites the value of other transactions in one schedule, then it also does so in the other schedule.
The notion of concurrency control is tied to the notion of transaction. A transaction defines a set of indivisible steps i.e., commands with Atomicity, Consistency, Isolation, and Durability which are commonly known as ACID properties.
- Atomicity: Either all or none of the steps of a transaction occur so the invariant of the shared objects is maintained.
- Consistency: A transaction takes a shared object from one legal state to other i.e., it maintains the invariant of the shared objects.
- Isolation: Events within transactions are hidden from other concurrently executing transactions.
- Durability: Once the system tells the user that a transaction has completed successfully, it will ensure the data is persistent on the database until they are overwritten explicitly by the user.