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: 

1. Read Phase:
   Values of committed data items from the database can be read by a transaction. Updates are only applied to local data versions. 
   
2. Validation Phase:
   Checking is performed to make sure that there is no violation of serializability when the transaction updates are applied to the database. 
   
3. 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 T_i, to check its validity:

1. Start(T_i): It is the time when T_i started its execution. 

2. Validation(T_i): It is the time when T_i just finished its read phase and begin its validation phase. 

3. Finish(T_i): the time when T_i 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 T_i performs.

2. Read_set: of a transaction contains all the read operations that T_i performs.

In the Validation phase for transaction T_i the protocol inspect that T_i doesn’t overlap or intervene with any other transactions currently in their validation phase or in committed. The validation phase for T_i checks that for all transaction T_j one of the following below conditions must hold to being validated or pass validation phase:

1. Finish(T_j)<Starts(T_i), since T_j finishes its execution means completes its write-phase before T_i started its execution(read-phase). Then the serializability indeed maintained. 

2. T_i begins its write phase after T_j completes its write phase, and the read_set of T_i should be disjoint with write_set of T_j.

3. T_j completes its read phase before T_i completes its read phase and both read_set and write_set of T_i are disjoint with the write_set of T_j.

Ex: Here two Transactions T_i and T_j are given, since TS(T_j)<TS(T_i) 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 T_j. Since T_i reads the old values of x(12) and y(15) while print(x+y) operation unless final write operation take place. 

Schedule-A

Tj	Ti
r(x) // x=12
	r(x)
	x=x-10 r(y) //y=15
	y=y+10 r(x)
<validate> print(x+y)
	<validate>
	w(x) w(y)

                            Schedule-A is a validated schedule

Advantages:

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.

Disadvantages:

1. Starvation: There might be a possibility of starvation for long-term transactions, due to a sequence of conflicting short-term transactions that cause the repeated sequence of restarts of the long-term transactions so on and so forth. To avoid starvation, conflicting transactions must be temporarily blocked for some time, to let the long-term transactions to finish.