Validation-Based Protocol, also known as Optimistic Concurrency Control, is a technique in DBMS used to manage concurrent transactions without locking data during execution. It assumes that conflicts between transactions are rare and delays conflict detection until the validation phase just before committing.
Why It's Called Optimistic Concurrency Control
- Assumes low interference among transactions.
- Does not check for conflicts during execution.
- All updates are done on local copies.
- At the end, a validation check ensures data consistency before writing to the database.
Phases of Validation-Based Protocol
This protocol operates in three main phases:
1. Read Phase:
- The transaction reads data and performs calculations using temporary (local) variables.
- No changes are made to the database yet.
2. Validation Phase:
- Before committing, the transaction checks for conflicts with other concurrently running transactions.
- If no conflict is found (i.e., serializability is preserved), it proceeds to the write phase.
- If validation fails, the transaction is aborted and restarted.
3. Write Phase:
- If validation passes, the transaction writes changes to the database.
- If validation fails, the transaction is aborted and may be restarted.
The diagram below shows the working of the transaction based protocol.
Validation-based protocol delays conflict checks until the end. It works well in systems where most transactions don’t interfere with each other.
- In low-conflict environments → high success rate.
- In high-conflict environments → frequent rollbacks, reduced efficiency.
Timestamps Used
Validation based protocols often use timestamps to manage the serialization order of transactions. Each transaction Ti is associated with three important timestamps:
- Start (Ti): The time when transaction Ti begins its execution (read phase).
- Validation (Ti): Time when Ti starts validation. Often used as its logical timestamp for serialization.
- 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 Ti performs.
- Read_set: A set of transaction that contains all the read operations that Ti performs.
Example:
Let’s consider two transactions where Tj starts before Ti, since TS(Tj) < TS(Ti) 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 Tj. Since Ti reads the old values of x(12) and y(15) while print (x+y) operation unless final write operation take place.
| Time | Tj (Earlier TS) | Ti (Later TS) | Notes |
|---|---|---|---|
| T0 | r(x) → x = 12 | Ti starts and reads x = 12 | |
| T1 | r(x) → x = 12 | Tj starts and reads x = 12 | |
| T2 | x = x - 10 | Tj computes new value for x | |
| T3 | r(y) → y = 15 | Ti reads y | |
| T4 | y = y + 10 | Ti computes new value for y | |
| T5 | r(x) | Tj re-reads x (local copy still 12) | |
| T6 | <validate> | Ti enters validation phase | |
| T7 | print(x + y) → 27 | Uses local x = 12, y = 15 | |
| T8 | <validate> | Tj enters validation phase | |
| T9 | w(x) | Tj writes x | |
| T10 | w(y) | Tj writes y |
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.
For Ti to successfully validate against Tj, the following two conditions should meet:
- 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.
