- 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:
- A schedule is
recoverable if:
- Claim:
- Every Avoid Cascading Rollback schedule is a recoverable schedule
- Proof:
- By the definition of an
ACR schedule, we have that:
- If a
transaction Tk
uses (= reads) a
value written
by
a transaction Ti, then
- transaction Ti must be a committed transaction
Thereofre, the ordering of operations in an ACR schedule must be as follows:
- The transaction Tk can
only commit
later:
- If a
transaction Tk
uses (= reads) a
value written
by
a transaction Ti, then
- Therefore, in an ACR schedule:
- A
transaction Tk will
commit
after every transaction
that transaction Tk
is
depending on:
By the definition of the recoverable schedule:
- An ACR schedule is also a recoverable schedule !!!!
- A
transaction Tk will
commit
after every transaction
that transaction Tk
is
depending on:
- By the definition of an
ACR schedule, we have that:
- Note:
- An ACR schedule can be non-serializable
- Example:
- Previously, we saw the
following
non-serializable schedule that
was recoverable
-- see
click here
- Consider the following
slightly modified
schedule:
- This schedule is
ACR:
(because T2 only
uses (reads) data 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
was recoverable
-- see
click here
- Structure of
schedules:
- Recall that:
- Transactions that uses 2-phased locking are conflict-serializable
- Fact:
- We can enforce an Avoid Cascaded Rollback schedule using a lock method called "strick" locking !!!