- The lock table is
implemented as:
-
Hash table
in main memory:
- The DB elements that has not been locked are not stored in the Hash table !!!
-
Hash table
in main memory:
- Each
lock table entry contains the
following (3) fields:
- Group (lock) mode
- Any transaction waiting?
- List of
lock requests
Graphically:
Meaning of the fields:
- Group mode =
the most stringent
lock mode
that has been
granted
on the database element
(to a
transaction)
- Waiting ?:
- Yes:
- if some transaction is waiting on a lock request for this DB element
- No
- if no transaction is waiting on a lock request for this DB element
- Yes:
- List of (lock) requests =
a (linked) list of
transactions that
has
made a
lock request for
this
DB element
- Some of these requests may have been granted
- Some of these requests may have been denied --- then the transaction is waiting for the request
The structure of an (lock) request in the is explained next
- Context:
where are the
lock requests ?
- The lock requests are
stored as
a list here:
- The lock requests are
stored as
a list here:
- The information
stored in
one lock request consists of:
- Transaction ID =
the identifier of the
transaction that
made the
lock request
- Lock mode =
the mode (type of lock) of the
lock requested
(e.g.: shared,
update,
exclusive, etc.)
- S (shared) = transaction has requested a shared lock on the database element
- U (update/upgrade) = transaction has requested a update lock on the database element
- X (exclusive) = transaction has requested a exclusive lock on the database element
- Wait? =
status of the
lock request
- No =
not waiting
I.e.: the transaction has obtained a lock in the requested mode !!!
- Yes
= waiting
I.e.: the transaction is waiting on the lock request (to become granted)
- No =
not waiting
- Next =
used to construct a
linked list of
all lock requests
for the same
database element
Example usage:
- Tnext =
a linking field used to
chain all the lock requests
made by the
same transaction
- A transaction T makes
multiple lock requests
- The Tnext field is used to link all requests made by the same transaction together
How is the Tnext field used:
Suppose a transaction T1 locks 2 database elements A and B:
Why do we need this data structure:
- When a transaction
completes (commit/abort), the
transaction manager must:
- Release all locks held by the transaction !!!
- The list of
locks held by
a transaction can
be used to:
- Find all locks held by the transaction quickly !!!
- A transaction T makes
multiple lock requests
- Transaction ID =
the identifier of the
transaction that
made the
lock request
- Summary/overview on
how to store
the lock requests made to
one database element
(A) in the figure below:
- Recall:
- One transaction can make multiple lock requests
- All lock requests made by
the same transaction are
chained/linked together:
This allows the DBMS to unlock all the locks held by a transaction when it commits/aborts