- We imposed the following
rules in
shared/exclusive locks:
- A transaction can
only hold
one of the
2 types of locks:
- a shared lock or
- an exclusive lock
- A transaction can
only hold
one of the
2 types of locks:
- Consequently:
- If a transaction
first
reads
a DB element and
later
writes the
same DB element, then:
- The transaction must request an exclusive lock for the DB element when it read the DB element
- If a transaction
first
reads
a DB element and
later
writes the
same DB element, then:
- Technically
it's very easy to
implement
upgradable locks:
- A transaction T that wants
to read a
DB element
first acquires
a shared lock
- We set the state of the lock to SHARED
- When transaction T wants
to write a
DB element
later,
it can
update the
shared lock
to an
exclusive lock:
- We simply set the state of the lock to EXCLUSIVE
- A transaction T that wants
to read a
DB element
first acquires
a shared lock
- Example:
- Example of interleaved
execution (possible schedule):
- Fact:
- Naive ("unannounced") lock upgrade is dangerous !!!!
Because:
- "Unannounced" lock upgrade can cause a new form of deadlock
- The danger of
upgrading locks:
- Indiscriminant ("unannounced") lock upgrade can result in deadlock with just one (1) DB element !!!
- Example transactions:
Possible interleaved execution:
- In contrast, if we
do not allow
lock upgrade:
- Transaction must obtain
an exclusive lock:
And there is no deadlock using one database element:
- Transaction must obtain
an exclusive lock: