- Fact:
- The is a way to
avoid the
deadlock problem involving
a single DB element
(as shown in the
previous example)
- The solution is:
- Announce your intension !!!
- The is a way to
avoid the
deadlock problem involving
a single DB element
(as shown in the
previous example)
- The update lock (ul(•))
operation:
- The update lock mode
gives a transaction the
privilege (= right) to
read a
DB element
- The update lock mode
does not
gives a transaction the
privilege to
write the
DB element
--- even though the name of the lock is called "update" !!!
- The update lock mode
does not
gives a transaction the
privilege to
write the
DB element
- An update lock
can be
upgraded later
to an exclusive lock
(which does give a transaction the privilege to write a DB element)
- The update lock mode
gives a transaction the
privilege (= right) to
read a
DB element
- Types
of locks:
- Shared lock (sl(•)):
- Gives a transaction the privilege to read a DB element
- Update lock (ul(•)):
- Gives a transaction the privilege to read a DB element
- Can be upgraded to exclusive lock later
- Exclusive lock
(xl(•)):
- Gives a transaction the privilege to write a DB element
- Shared lock (sl(•)):
- Lock compatibility matrix:
Explanation:
- Most of the
entries are
obvious
Except the two highlighted with yellow
- Case 1:
Reason why the request is compatible:
- A transaction holds a
shared lock will
not update
the DB element
- This situation is similar to a case where no transaction is running !!!
- So we can allow the read (and later update) to proceed
- A transaction holds a
shared lock will
not update
the DB element
- Case 2:
Reason why the request is not compatible:
- A transaction T holds a
update lock can
write
the DB element later
- We also know the
transaction T is
ahead of the
currently requesting
transaction !!!
- Therefore, the currently requesting transaction should read the value that transaction T will write later !!!
- We also know the
transaction T is
ahead of the
currently requesting
transaction !!!
-
If
(hypothetically speaking)
we
allow the
shared (read) rqeuest to
proceed,
then:
- the transcation will read the old value (before the write by the transaction T has talen place)
This is wrong, because the request must read the value that transaction T will write later
- So:
- We must make the shared lock request wait !!!
- A transaction T holds a
update lock can
write
the DB element later
- Most of the
entries are
obvious
- Previous example of
transactions, now with
update locks:
There is no deadlock now:
