- We will first study
the exclusive lock:
- Lock states:
- unlocked
- (exclusive) locked
- Lock states:
- Lock operations:
- lock:
- lock requests is granted if
the lock state is unlocked
The state of the lock becomes locked
- lock requests is denied if the lock state is locked
- lock requests is granted if
the lock state is unlocked
- unlock:
- The state of the
lock will become
unlocked
Only applicable if the transaction currently hold the lock
- The state of the
lock will become
unlocked
- lock:
- Notations:
- ℓi(X)
=
transaction i requests a
lock on
DB element X
- ui(X) = transaction i requests to unlock the DB element X
- ℓi(X)
=
transaction i requests a
lock on
DB element X
- Rules:
- When a transaction T want to
perform an action (read/write) on
a DB element X:
- Transaction T must first obtain the lock on DB element X
- The transaction T must release all locks before it terminates
Schematically:
Ti: .... ℓi(X) ri(X) .... ui(X) .... (read) .... ℓi(X) wi(X) .... ui(X) .... (write)
- When a transaction T want to
perform an action (read/write) on
a DB element X:
- Note:
- A
transactions must
hold the
lock to
perform an
action
So this is not allowed:
.... ℓi(X) .... ui(X) wi(X) .... (write)
- A
transactions must
hold the
lock to
perform an
action
- Lock schedule:
- Lock schedule = a schedule that uses locks to make re-ordering decisions in the execution of the actions of the transactions
- Recall: the schematics of
a (general) scheduler:
Explanation:
- The scheduler will
grant
the lock request
for an operation if the
request
cannot result in an
inconsistent state
- The scheduler will deny the lock request for an operation if the request can result in an inconsistent state
- The scheduler will
grant
the lock request
for an operation if the
request
cannot result in an
inconsistent state
- The exact implementation of
a lock table will
be discussed later
- For now, imagine that:
- A lock table is a
set of tuples of
the following
format:
( DB Element, Transaction holding lock )
Example:
( X, T1 ) ( Y, T2 ) ...
- A lock table is a
set of tuples of
the following
format:
- Note:
- Due to the locking rule
of exclusive locks:
- Only one transaction can hold a lock !!!!
- Due to the locking rule
of exclusive locks:
- Transactions:
- Transactions
augmented with
lock operations:
- Example of a schedule with
locks:
Notice that:
- The transactions
obeys the
locking rules:
- .... ℓi(X) ri(X) .... wi(X) ui(X) ....
- However:
- The resulting schedule is non-serializable
(Because serial schedules of transactions T1 and T2 will preserve the property A = B !!!)
- The transactions
obeys the
locking rules:
- Conclusion:
- The locking rules is insufficient to ensure (conflict)-serializability !!!
- Consider a
slightly changed
order in the
transactions:
- We re-order these
2 unlock/lock
operations in the
previous example:
Result:
- We re-order these
2 unlock/lock
operations in the
previous example:
- Now consider the
execution of the
same schedule:
Conclusion:
- The execution
results in
a consistent state !!!
- A = B !!!
- So locks
can force
a schedule to
change the
order of
execution of
the actions so that:
- The resulting execution of the schedule is conflict-serializable
Question:
- What is the secret ingredient that we need to add to make locking a sufficient technique to ensure conflict-serializability ????
- The execution
results in
a consistent state !!!