- Fact:
- If only exclusive locks are used, the Part 1 of the scheduler is very simple
- Operation of the
Part 1 of the
scheduler
using only
exclusive locks:
- Read:
- Write:
- Commit/Abort:
Comment:
- Part 1 of the
scheduler can:
- make the choice of the lock action without further information from the transaction that made the lock request !!!
- Read:
- Fact:
- In the shared/update/exclusive locking scheme, the scheduler needs help from the transaction to make the lock choice decision !!!
- Example: the same
(read) operation
will result in
different lock actions !!!
- Read operation
without
a future write operation:
- Read operation
with
a future write operation:
- Read operation
without
a future write operation:
- How to help
part 1 of the
scheduler:
- The SQL query processor will
send
different types of
read requests to
the scheduler:
- SELECT command: sends an
ordinary read request
- UPDATE command: sends a special read request (with possible future write on the DB element)
- SELECT command: sends an
ordinary read request
- (User) program that
access the database:
- The compiler must detect whether the DB element read will be updated later in the program
Result: you will have 2 types of read requests:
- Read operation
without
a future write operation:
- Read operation
with
a future write operation:
- The SQL query processor will
send
different types of
read requests to
the scheduler:
- Part 2 of
scheduler
is responsible for
- Maintaining the lock table
We will discuss this next (in the next webpage)