Recoverability
Recoverability
A non-serial schedule which is not serializable is called as a non-serializable
schedule.
A non-serializable schedule is not guaranteed to produce the same effect as
produced by some serial schedule on any consistent database.
Characteristics-
Non-serializable schedules-
may or may not be consistent
may or may not be recoverable
Irrecoverable Schedules-
If in a schedule,
A transaction performs a dirty read operation from an uncommitted transaction
And commits before the transaction from which it has read the value
then such a schedule is known as an Irrecoverable Schedule.
Example-
Consider the following schedule-
Here,
T2 performs a dirty read operation.
T2 commits before T1.
T1 fails later and roll backs.
The value that T2 read now stands to be incorrect.
T2 can not recover since it has already committed.
Recoverable Schedules-
If in a schedule,
A transaction performs a dirty read operation from an uncommitted transaction
And its commit operation is delayed till the uncommitted transaction either
commits or roll backs
then such a schedule is known as a Recoverable Schedule.
Here,
The commit operation of the transaction that performs the dirty read is delayed.
This ensures that it still has a chance to recover if the uncommitted transaction
fails later.
Example-
Consider the following schedule-
Here,
T2 performs a dirty read operation.
The commit operation of T2 is delayed till T1 commits or roll backs.
T1 commits later.
T2 is now allowed to commit.
In case, T1 would have failed, T2 has a chance to recover by rolling back.
Method-01:
Check whether the given schedule is conflict serializable or not.
If the given schedule is conflict serializable, then it is surely recoverable. Stop
and report your answer.
If the given schedule is not conflict serializable, then it may or may not be
recoverable. Go and check using other methods.
Thumb Rules
All conflict serializable schedules are recoverable.
All recoverable schedules may or may not be conflict serializable.
Method-02:
Check if there exists any dirty read operation.
(Reading from an uncommitted transaction is called as a dirty read)
If there does not exist any dirty read operation, then the schedule is surely
recoverable. Stop and report your answer.
If there exists any dirty read operation, then the schedule may or may not be
recoverable.
If there exists a dirty read operation, then follow the following cases-
Case-01:
If the commit operation of the transaction performing the dirty read occurs before the
commit or abort operation of the transaction which updated the value, then the schedule
is irrecoverable.
Case-02:
If the commit operation of the transaction performing the dirty read is delayed till the
commit or abort operation of the transaction which updated the value, then the schedule
is recoverable.
Thumb Rule
No dirty read means a recoverable schedule.
Recoverable Schedules-
If in a schedule,
A transaction performs a dirty read operation from an uncommitted transaction
And its commit operation is delayed till the uncommitted transaction either
commits or roll backs
then such a schedule is called as a Recoverable Schedule.
1. Cascading Schedule
2. Cascadeless Schedule
3. Strict Schedule
Cascading Schedule-
If in a schedule, failure of one transaction causes several other dependent
transactions to rollback or abort, then such a schedule is called as
a Cascading Schedule or Cascading Rollback or Cascading Abort.
It simply leads to the wastage of CPU time.
Example-
Here,
Transaction T2 depends on transaction T1.
Transaction T3 depends on transaction T2.
Transaction T4 depends on transaction T3.
In this schedule,
The failure of transaction T1 causes the transaction T2 to rollback.
The rollback of transaction T2 causes the transaction T3 to rollback.
The rollback of transaction T3 causes the transaction T4 to rollback.
Such a rollback is called as a Cascading Rollback.
NOTE-
If the transactions T2, T3 and T4 would have committed before the failure of transaction
T1, then the schedule would have been irrecoverable.
Cascadeless Schedule-
If in a schedule, a transaction is not allowed to read a data item until the last transaction
that has written it is committed or aborted, then such a schedule is called as
a Cascadeless Schedule.
In other words,
Cascadeless schedule allows only committed read operations.
Therefore, it avoids cascading roll back and thus saves CPU time.
Example-
NOTE-
Cascadeless schedule allows only committed read operations.
However, it allows uncommitted write operations.
Example-
Strict Schedule-
If in a schedule, a transaction is neither allowed to read nor write a data item until the
last transaction that has written it is committed or aborted, then such a schedule is called
as a Strict Schedule.
In other words,
Strict schedule allows only committed read and write operations.
Clearly, strict schedule implements more restrictions than cascadeless schedule.
Example-
1. Result Equivalence
2. Conflict Equivalence
3. View Equivalence
Remember-
Strict schedules are more strict than cascadeless schedules.
All strict schedules are cascadeless schedules.
All cascadeless schedules are not strict schedules.