- Recall:
cascading rollback:
- If
transaction T1
has read (used)
dirty data
written by
the
uncommitted transaction
T2,
then:
- When
transaction T1
aborts, then:
- We must also abort transaction T2 !!!
- When
transaction T1
aborts, then:
- If
transaction T1
has read (used)
dirty data
written by
the
uncommitted transaction
T2,
then:
- The cause of
cascading rollback:
- Allowing transactions to read dirty data
- Fact:
- A recoverable schedule may require cascading rollbacks
- Example:
- Consider the following
serializable and
recoverable schedule:
T2
- If the
user/system decides to
abort the
transaction T1
right before it
commits:
then
- We will rollback
transaction T1
(because it was aborted):
- But
we must also
rollback the
transaction T2
because of the
dirty read:
Result: cascaded rollback:
- We will rollback
transaction T1
(because it was aborted):
- Consider the following
serializable and
recoverable schedule:
- ACR (Avoid Cascading Rollback) schedule:
- A schedule is a
ACR schedule if:
- Every read operation made by a transaction will read (= use) values written by committed transactions
- A schedule is a
ACR schedule if:
- In other words:
- An ACR schedule forbids the reading of dirty data !!!!
- Committed:
- A transaction is
committed when:
- The commit record has been written to disk !!!
- A transaction is
committed when:
- Because:
- Otherwise, if the system crashes; the recovery procedure will mark transactions with no commit record as aborted !!!
- Example of a
non-ACR schedule:
- The following schedule is
not ACR:
-
Because:
- Transaction T2 has
read
dirty data
written by uncommitted
transaction T1:
Therefore:
- If transaction T1 aborts, we must also abort transaction T2
- Transaction T2 has
read
dirty data
written by uncommitted
transaction T1:
- The following schedule is
not ACR:
- Example of a
ACR schedule:
- The following schedule is
ACR:
Because:
- Transaction T2 has read "guaranteed" data written by a committed transaction T1
- Notice that:
- When T2 reads the database element B, we already know the value written by (committed transaction) T1 will persist in the database !!!
- The following schedule is
ACR:
- Claim:
- Every ACR schedule is a recoverable schedule
- Recall the
definition of
Recoverable schedule:
(
click here:
)
- A schedule is
recoverable if:
- each transaction commits only after all transactions from which it has read has committed
Graphically:
Then: transaction Tk must commit only after the transactions T1, T2 and T3 have committed
- A schedule is
recoverable if:
- Proof:
- By the definition of an
ACR schedule, we have that:
- Whenever a
transaction Tk
reads a
value written
by
a transaction Ti, the
ACR schedule
must contains an
intermediate commit action:
- Whenever a
transaction Tk
reads a
value written
by
a transaction Ti, the
ACR schedule
must contains an
intermediate commit action:
- Therefore, in an ACR schedule:
- The read operations are
preceeded by
the commits of the
dependent transactions:
- Therefore,
Tk will
commit
after every
dependent transactions:
Therefore:
- Every ACR schedule is also recoverable !!!!
- The read operations are
preceeded by
the commits of the
dependent transactions:
- By the definition of an
ACR schedule, we have that:
- Claim:
- An ACR schedule can be non-serializable
- Example:
- Previously, we saw the
following
non-serializable schedule that
is recoverable
-- see
click here
- Consider the following
slightly modified
schedule:
- This schedule is
ACR:
(T2 only
read from
committed transactions)
because we did not change the position of the read/write operation in the schedule:
- This schedule is still non-serializable !!!!!
- Previously, we saw the
following
non-serializable schedule that
is recoverable
-- see
click here
- Structure of
schedules:
