Multiversion Locking Protocol with Freezing for Secure Real-Time Database Systems

1
Multiversion Locking Protocol with Freezing for
Secure Real-Time Database Systems

• Submitted to
• Dr. Badie Sartawi
• Submitted by
• Nizar Handal 9810130
• 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
  its timestamp is equal to or larger than the
  data item write-timestamp.
• A transaction can write on a data item if and
  only if its 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 datums 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