- Previously, we have
studied the
following 2 problems
separately:
-
Atomicity/Recoverability:
- How to ensure that:
- All updates made by
a transactions are
incorporated into the
database
or
- None of the updates made by a transactions are incorporated into the database
- All updates made by
a transactions are
incorporated into the
database
or
- Techniques learned:
- undo logging
- redo logging
- undo/redo logging
However:
- We did not consider
serializability when we
solved the
atomicity/recoverability problem:
- Can the logging techniques result in an inconsistent state when transactions run concurrently ????
- How to ensure that:
- Serializability:
- Ensure that
a concurrent execution of
transactions is
equivalent to
some serial execution
- Techniques learned:
- 2 Phased-Locking that ensures conflict-serializability
- Ensure that
a concurrent execution of
transactions is
equivalent to
some serial execution
- However:
- We did not consider recoverability when we discussed the serializability problem:
-
Atomicity/Recoverability:
- Question studied in this
chapter:
- How do the
concepts:
- Recoverability
- Serializability
interact with one another
- How do the
concepts:
- Consider the following
2 transactions that
uses 2 phased-locking:
Recall:
- 2 phased-locking will guarantee that a interleaved execution of the transactions will be conflict serializable
- Consider the
following concurrent execution
of these 2 transactions:
- We use undo logging
- Transaction T1
starts first and
updates
the database element A on
disk
Because we wrote A to disk, we will first write the undo log <T1, A, 25> to the undo log
- Later,
the transaction T2
starts and
reads the
the database element A on
disk:
Notice:
- T2 has used the value (A = 125) that was updated by T1 that has not yet committed !!!
- Later,
the transaction T1 is
aborted
(by the user or system) and the
undo logging will
undo the update:
- T2 continues
and completes:
Notice that:
- T2 is the
only
committed transaction
Therefore:
- The schedule is trivially serializable !!!! (because the schedule only has 1 transaction)
- However:
- The result of
the execution of
this schedule is
inconsistent:
A (= 250) ≠ B (= 50)
(T1 and T1 will maintain A = B and result does not)
- The result of
the execution of
this schedule is
inconsistent:
- We use undo logging
- Observation:
- When T1
aborts,
the update w1(A)
performed by
T1 will be
undone by
the logging method:
Therefore:
- Transaction T2 have read an non-existing value due to an aborted transaction !!!
- The cause of the
inconsistency:
- The logging method
does not prevent
T2 from
reading the
updated value (125)
from T1:
- The logging method
does not prevent
T2 from
reading the
updated value (125)
from T1:
- Result:
- Transaction T2 has used a incorrect initial value in its execution !!!
- When T1
aborts,
the update w1(A)
performed by
T1 will be
undone by
the logging method:
- How
concurrent execution of
transaction can
interfere
with recoverability:
- Fact:
- Data that has been updated by uncommitted transaction can revert back to the original value
- Concurrent execution can
interfere with
recoverability through:
- A transaction T2 that has read (used) some data updated by an (earlier) uncommitted transaction T2 that is aborted later
- Fact:
- Dirty data
- A DB element is
dirty if
- the DB element has been written (= updated) by a transaction that is not (yet) committed
Example:
- A DB element is
dirty if
- Dirty data can
be found:
- In
(memory) buffers maintained
by the DBMS buffer manager --
this can happen in redo-logging
- Transactions can
update a
database element
stored in the
memory buffer in
redo logging
- A read operation
to a database element will
first access the
copy in the
memory buffer
(through the translation table
see:
click here)
Result:
- This read operation will access dirty data if the updating transaction is not committed
- Transactions can
update a
database element
stored in the
memory buffer in
redo logging
- On disk
if we use undo logging
- Uncommitted transactions can
update a
database element
stored on
disk in
undo logging:
- A read operation
to a database element can
access the
database element on
disk
- This read operation will access dirty data if the updating transaction is not committed
- Uncommitted transactions can
update a
database element
stored on
disk in
undo logging:
Fact:
- Either forms of dirty data (stored in memory or on disk) can cause trouble for serializability
- In
(memory) buffers maintained
by the DBMS buffer manager --
this can happen in redo-logging
- Fact:
- Dirty data == unreliable data !!!
- Consequence of
using (= reading) dirty data:
- A transaction (e.g. T2)
that has
used (= read)
dirty data:
can only be allowed to complete (= committed) if:
- The transaction that wrote (= created) the dirty data has committed !!!
- Example: (see
figure above)
- Transaction T2 can
only be allowed to
commit
if:
- Transaction T1 has committed !!!
- Transaction T2 can
only be allowed to
commit
if:
- A transaction (e.g. T2)
that has
used (= read)
dirty data:
- Logical consequence of the
above result:
-
Cascading
rollbacks (= aborts)
!!!
(Discussed next)
-
Cascading
rollbacks (= aborts)
!!!