1. Multiversion Locking Protocol with Freezing for Secure Real-Time Database Systems
Submitted to
Dr. Badie Sartawi
Submitted by
Nizar Handal
Course
Database II CS342
Semester
Spring 2003

2. Table Of Contents Introduction and some Definitions
Lock based protocols
Two phase locking
Timestamp based protocol
Timestamp-ordering protocol
Multiversion protocols
Multiversion two-phase locking
Multiversion locking protocol with Freezing method

3. Introduction and some Definitions
Real-time application: an application which satisfy timing constraints associated with transactions which are typically expressed in terms of deadlines.
Multilevel secure database system: is a system which is shared by users with more than one clearance level and which contains data of more than one classification level.
In order for MLS/DBS to be correct it must satisfy two requirements, the elimination of covert channel and the other is the prevention of starvations of high level transactions.

4. Lock based protocols Locks restrict access to object.
Must always lock an object before accessing it (reading or writing).
Simple locking protocol:
Shared locks: grant read (but not write) access to an object; multiple transactions may have shared access.
Exclusive locks: grants read and write access to an object; only one transaction may have exclusive access.
Used for delete and inserts as well.

5. Two phase locking
The most common technique for producing serializable schedules.
Each transaction has two phases with respect to locks:
Growing phase: the transaction may acquire locks.
Shrinking phase: the transaction releases locks.
Once a transaction release a lock, it may not acquire any new locks (that is gone from the growing phase into the shrinking phase).
Protocol based on single version Cannot avoid the starvation of low-priority transaction, because low-priority transaction can be delayed or aborted by high-priority transaction.

6. Timestamp based protocol
Assign timestamp at transaction begin time.
Use timestamps to maintain serializability order.
With data item we can associate two stamps:
Read-timestamp: the largest timestamp of any transaction that successfully read the data item.
Write-timestamp: the largest timestamp of any transaction that successfully wrote o the data.

7. Timestamp-ordering protocol
When we reject a request, we rollback the requesting transaction.
A transaction can read a data item if and only if it’s timestamp is equal to or larger than the data item write-timestamp.
A transaction can write on a data item if and only if it’s timestamp is equal to or larger than the data item read and write timestamp.
Since no transaction ever waits, no deadlocks.

8. Multiversion protocols
Make a copy of each item on a write.
On reads, select the appropriate item to read, mean that the transaction can read only the most recently certified version in order to meet one-copy serializability.
Protocols based on multiversions requires more storage than those based on a single version.
Each transaction has a timestamp.
Each datum consists of a set of data, associated with each, value, read-timestamp and write-timestamp.

9. Multiversion two-phase locking
For update transactions, use rigorous two-phase locking.
On writes, create a new copy of each datum with an infinite timestamp.
During commit, assign a counter-based timestamp to the transaction. Set each datum’s timestamp to this value.
for read-only transactions:
Obtain a timestamp at the beginning of execution.
Follow the multiversion timestamp ordering protocol for reads.

10. Multiversion locking protocol with Freezing method
The conflict occurs when high-level transaction with high-priority and a low-level transaction with low-priority wants to read or write on the same data item, where non of them should be blocked by the other, so that covert channels are avoided, this called SP-conflict.
For that, the multiversion locking protocol does not guarantee the elimination of conflicts between two transactions.
To solve this problem a new protocol is proposed, so that the transaction with lower priority is should be frozen by the transaction with higher priority.

11. The End