Validation Based Protocol in DBMS
Validation Based Protocol is also called Optimistic Concurrency Control Technique. This protocol is used in DBMS (Database Management System) for avoiding concurrency in transactions. It is called optimistic because of the assumption it makes, i.e. very less interference occurs, therefore, there is no need for checking while the transaction is executed.
In this technique, no checking is done while the transaction is been executed. Until the transaction end is reached updates in the transaction are not applied directly to the database. All updates are applied to local copies of data items kept for the transaction. At the end of transaction execution, while execution of the transaction, a validation phase checks whether any of transaction updates violate serializability. If there is no violation of serializability the transaction is committed and the database is updated; or else, the transaction is updated and then restarted.
Optimistic Concurrency Control is a three-phase protocol. The three phases for validation based protocol:
- Read Phase:
Values of committed data items from the database can be read by a transaction. Updates are only applied to local data versions.
- Validation Phase:
Checking is performed to make sure that there is no violation of serializability when the transaction updates are applied to the database.
- Write Phase:
On the success of the validation phase, the transaction updates are applied to the database, otherwise, the updates are discarded and the transaction is slowed down.
The idea behind optimistic concurrency is to do all the checks at once; hence transaction execution proceeds with a minimum of overhead until the validation phase is reached. If there is not much interference among transactions most of them will have successful validation, otherwise, results will be discarded and restarted later. These circumstances are not much favourable for optimization techniques, since, the assumption of less interference is not satisfied.
Validation based protocol is useful for rare conflicts. Since only local copies of data are included in rollbacks, cascading rollbacks are avoided. This method is not favourable for longer transactions because they are more likely to have conflicts and might be repeatedly rolled back due to conflicts with short transactions.
In order to perform the Validation test, each transaction should go through the various phases as described above. Then, we must know about the following three time-stamps that we assigned to transaction Ti, to check its validity:
1. Start(Ti): It is the time when Ti started its execution.
2. Validation(Ti): It is the time when Ti just ﬁnished its read phase and begin its validation phase.
3. Finish(Ti): the time when Ti end it’s all writing operations in the database under write-phase.
Two more terms that we need to know are:
1. Write_set: of a transaction contains all the write operations that Ti performs.
2. Read_set: of a transaction contains all the read operations that Ti performs.
In the Validation phase for transaction Ti the protocol inspect that Ti doesn’t overlap or intervene with any other transactions currently in their validation phase or in committed. The validation phase for Ti checks that for all transaction Tj one of the following below conditions must hold to being validated or pass validation phase:
1. Finish(Tj)<Starts(Ti), since Tj finishes its execution means completes its write-phase before Ti started its execution(read-phase). Then the serializability indeed maintained.
2. Ti begins its write phase after Tj completes its write phase, and the read_set of Ti should be disjoint with write_set of Tj.
3. Tj completes its read phase before Ti completes its read phase and both read_set and write_set of Ti are disjoint with the write_set of Tj.
Ex: Here two Transactions Ti and Tj are given, since TS(Tj)<TS(Ti) so the validation phase succeeds in the Schedule-A. It’s noteworthy that the final write operations to the database are performed only after the validation of both Ti and Tj. Since Ti reads the old values of x(12) and y(15) while print(x+y) operation unless final write operation take place.
Schedule-A x=x-10 r(y) //y=15 y=y+10 r(x) <validate> print(x+y) w(x) w(y)
Tj Ti r(x) // x=12 r(x) <validate>
Schedule-A is a validated schedule
1. Avoid Cascading-rollbacks: This validation based scheme avoid cascading rollbacks since the final write operations to the database are performed only after the transaction passes the validation phase. If the transaction fails then no updation operation is performed in the database. So no dirty read will happen hence possibilities cascading-rollback would be null.
2. Avoid deadlock: Since a strict time-stamping based technique is used to maintain the specific order of transactions. Hence deadlock isn’t possible in this scheme.
1. Starvation: There might be a possibility of starvation for long-term transactions, due to a sequence of conﬂicting short-term transactions that cause the repeated sequence of restarts of the long-term transactions so on and so forth. To avoid starvation, conﬂicting transactions must be temporarily blocked for some time, to let the long-term transactions to ﬁnish.
Attention reader! Don’t stop learning now. Practice GATE exam well before the actual exam with the subject-wise and overall quizzes available in GATE Test Series Course.
Learn all GATE CS concepts with Free Live Classes on our youtube channel.