- Fact:
- Concurrent execution of transactions can cause the database state to become inconsistent
Example:
- Consider the folloiwng 2 transactions:
T1: (transfer $1 from B to A) Read(A) A = A + 1 Write(A) Read(B) B = B - 1 Write(B)
T2: (transfer $2 from B to A) Read(A) A = A + 2 Write(A) Read(B) B = B - 2 Write(B) - Serial
(= non-concurrent)
execution:
Initial data value: A = 10 B = 10 A + B = 20
T1: Read(A) A = A + 1 Write(A) Read(B) B = B - 1 Write(B)
A = 11 B = 9 A + B = 20
T2: Read(A) A = A + 2 Write(A) Read(B) B = B - 2 Write(B)
A = 13 B = 7 A + B = 20
- Concurrent execution:
Initial data value: A = 10 B = 10 A + B = 20
T1: T2: Read(A) (10) Read(A) A = A + 2 Write(A) ---> A = 12 Read(B) B = B - 2 Write(B) ---> B = 8 A = A + 1 (11) Write(A) ----> A = 11 Read(B) (8) B = B - 1 Write(B) ----> B = 7
Final data value: A = 11 B = 7 A + B ≠ 20 !!!
- Observed fact
from the above example:
- The ordering of
operations (actions)
of different transactions
can affect
the consistency of the
database
- The ensure consistency of
the data:
- We must impose a certain ordering on the operations from different transaction
Note: we still need to define what this "ordering" is...
But we do know that we need some kind of ordering just by looking at the 2 examples
- The ordering of
operations (actions)
of different transactions
can affect
the consistency of the
database
- Scheduler:
- Scheduler =
the software component in
a DBMS that is
responsible for
- regulating (= scheduling) the executions of the actions (= read/write operations) of the transactions
- Scheduler =
the software component in
a DBMS that is
responsible for
- Concurrency control:
- Concurrency control =
the procedure/algorithm
to
ensure/guarantee that:
- a concurrent execution of the actions (operations) in (multiple) transactions will preserve the consistency of the database
- Concurrency control =
the procedure/algorithm
to
ensure/guarantee that:
- Software organization of a
DBMS:
Expanation:
- Transactions submit
(read/write) requests for
database elements to the
Transaction Manager
- The transaction manager
will write log records and
then forward
the (read/write) requests
to the
Scheduler
- The Scheduler
can
grant or
delay the
read/write) requests based on the
currently granted requests
- If the read/write request is
safe:
- The scheduler will grant the read/write request and the transaction can continue
- If the read/write request is
unsafe:
- The scheduer will delay the request and the transaction will wait
A commonly used technique to decide on grant/delay is:
- Locking
(Will be discussed soon)
- If the read/write request is
safe:
- Transactions submit
(read/write) requests for
database elements to the
Transaction Manager
- Note:
- In
some concurrency control techniques
(e.g., locking),
the scheduler may
need to
abort transactions !!!
- This happens when
transactions are
dead locked...
(Discussed later)
- This happens when
transactions are
dead locked...
- In
some concurrency control techniques
(e.g., locking),
the scheduler may
need to
abort transactions !!!
- Topics that
will be disccused:
- Define the
correctness of a
concurrent execution
of transaction:
- This definition is
called "serializability"
Serializable schedule (order of execution) will guarantee data consistency
- This definition is
called "serializability"
- Serializability turns out to be
impractical to
implement
We will look at a subset of correct schedules called:
- Conflict Serializability
This notion of correctness can be implemented using locks.
- Finally,
we will study
how to
implement
concurrent execution of
transactions are
conflict serializable by
using various kinds
of locks:
- Exclusive locks
- Shared/exclusive locks
- Shared/update/exclusive locks
- Shared/increment/exclusive locks
- Define the
correctness of a
concurrent execution
of transaction: