Multi-version protocol minimizes the delay for reading operation and maintains different versions of data items. For each writes operation performed, it creates a new version of transaction data so that whenever any transaction performs read operation to read that data then the appropriate created data version is selected by the control manager to make that read operation conflict-free and successful.
When the write operation and new version of data is created then that new version contains some information that is given below
- Content: This field contains the data value of that version.
- Write_timestamp: This field contains the timestamp of the transaction whose new version is created.
- Read_timestamp: This field contains the timestamp of the transaction of that transaction that will read that newly created value.
Now let us understand this concept using an example. Let T1 and T2 be two transactions having timestamp values 15 and 10, respectively.
The transaction T2 calls for a write operation on data (let’s say X) from the database. As T2 calls write operation, then a new version of data value X is created, which contains the value of X, timestamp of T2, and timestamp of that transaction which will read X, but in this case, no one is reading the newly created value so that filed remains empty.
| X | 10 |
Now let the transaction T1 (having timestamp 15) call a read operation to read the newly created value X, then the newly created variable contained will be
| X | 10 | 15 |
Now let’s discuss some important cases:
If timestamp of T2 is less than or equal to timestamp of T1 then
- Read(X) operation performed by T1: In this case, content of X is returned to T1.
- Write(X) operation performed by T1: In this case, T1 will be rolled back if timestamp of T1 is smaller than timestamp of read operation on X. And if timestamp of T1 is equal to the timestamp of write operation on X then the new version is created again with new contents.