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. 

Optimistic Concurrency Control Technique

In this technique, no checks are performed during the execution of the transaction. Until the transaction reaches its end, updates are not applied directly to the database. Instead, all updates are made to local copies of the data items maintained for the transaction. At the end of the transaction's execution, a validation phase checks whether any of the transaction’s updates violate serializability. If there is no violation, the transaction is committed and the database is updated. Otherwise, the transaction is aborted and restarted.

Optimistic Concurrency Control is a three-phase protocol. A transaction goes through three phases: 

• Read Phase:
  
  • The transaction reads data and performs calculations using temporary (local) variables.
  • No changes are made to the database yet.

• Validation Phase:
  • Before committing, the transaction checks for conflicts with other concurrently running transactions.
  • It validates that executing this transaction won't violate serializability.

• Write Phase:
  • If validation passes, the transaction writes changes to the database.
  • If validation fails, the transaction is aborted and may be restarted.

The flow diagram below shows the working of the transaction based protocol.

The idea behind optimistic concurrency control is to defer all conflict checks until the end of the transaction, allowing execution to proceed with minimal overhead until the validation phase. If there is little interference among transactions, most validations will succeed. However, if conflicts are common, transactions may frequently fail validation, causing results to be discarded and the transactions to be restarted. These conditions are not favorable for optimization, as the core assumption of low interference is violated.

The validation-based protocol is best suited for environments where conflicts are rare. Since it operates on local copies of data, rollbacks do not affect other transactions, effectively avoiding cascading rollbacks. However, this method is not ideal for long-running transactions, as they are more likely to encounter conflicts with short transactions and may be repeatedly rolled back.

Timestamps Associated with Validation-Based Protocols

Validation based protocols often use timestamps to manage the serialization order of transactions. Key timestamps associated with a transaction Ti​ include:

• Start (Ti​): The time when transaction Ti​ begins its execution (read phase).

• Validation (Ti​): The time when transaction Ti​ finishes its read phase and starts the validation phase. This timestamp is often used as the timestamp of the transaction for serialization purposes (TS(Ti​) = Validation(Ti​)).

• Finish (Ti​): The time when transaction Ti​ completes its write phase (if validation is successful).

Two more terms that we need to know are:

• Write_set: A set of transaction that contains all the write operations that T_i performs.

• Read_set: A set of transaction that contains all the read operations that T_i performs.

Transaction Schedule

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.

Example : 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 noted 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. 

Analysis

• Both Tj and Ti read the old values (x = 12, y = 15) before any writes occur.

• Ti validates before Tj writes, so it reads consistent, unmodified data.

• Tj’s writes occur only after validation, so there is no conflict during Ti's validation phase.

• Validation succeeds for both transactions:
  • Condition 1 applies: Finish(Tj) < Start(Ti) is not true.
  • But Condition 2 applies: Ti’s read set does not intersect with Tj’s write set at the time of validation.

• Both transactions can commit successfully.

Advantages of Validation-Based Protocols

• High Concurrency: Since no locks are acquired during the read phase, multiple transactions can access the same data items concurrently, potentially leading to higher throughput.

• Deadlock-Free: The absence of locks eliminates the possibility of deadlocks.

• No Cascading Rollbacks: Because updates are applied to the database only after successful validation, a transaction’s failure does not cause other transactions that read its (uncommitted) data to rollback.

Disadvantages of Validation-Based Protocols

• Validation Overhead : The validation process itself introduces overhead.

• Transaction Conflicts : If conflicts are frequent, a significant number of transactions might fail validation and need to be restarted which leads to wastage of work and reduced performance.

• Starvation : Long transactions might repeatedly fail validation if shorter transactions, frequently commit before them.