 |
VOOZH | about |
|
VOOZH | about |
In a Database Management System (DBMS), multiple transactions often run at the same time, and their execution order is called a schedule. It is important to ensure that these schedules do not cause data loss or inconsistencies, especially if a failure occurs.
A recoverable schedule ensures that the database can return to a consistent state after a transaction failure.
In this type of schedule:
Recoverable Schedule prevents data inconsistencies and ensures that no transaction commits based on unverified changes, making recovery easier and safer.
Example:
S1: R1(x), W1(x), R2(x), R1(y), R2(y), W2(x), W1(y), C1, C2;
The given schedule follows the order of Ti->Tj => C1->C2. Transaction T1 is executed before T2 hence there is no chance of conflict occurring. R1(x) appears before W1(x) and transaction T1 is committed before T2 i.e. completion of the first transaction performed the first update on data item x, hence given schedule is recoverable.
Let us see an example of an unrecoverable schedule to clear the concept more.
S2: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), W3(y), R2(y), W2(z), W2(y), C1, C2, C3;
Ti->Tj => C2->C3 but W3(y) executed before W2(y) which leads to conflicts thus it must be committed before the T2 transaction. So given schedule is unrecoverable. if Ti->Tj => C3->C2 is given in the schedule then it will become a recoverable schedule.
Example:
Note: A committed transaction should never be rollback. It means that reading value from uncommitted transaction and commit it will enter the current transaction into inconsistent or unrecoverable state this is called Dirty Read problem.
A cascade-less schedule ensures that if one transaction fails, it does not cause multiple other transactions to roll back.
A transaction is not allowed to use (read) uncommitted data from another transaction until that transaction is fully committed. This prevents cascading rollbacks, where a failure in one transaction forces many others to undo their changes. If a transaction fails before committing, only its own changes are undone, but other transactions that have read its data do not need to roll back, making the recovery process simpler and more efficient.
Example:
S3: R1(x), R2(z), R3(x), R1(z), R2(y), R3(y), W1(x), C1, W2(z), W3(y), W2(y), C3, C2;
In this schedule W3(y) and W2(y) overwrite conflicts and there is no read, therefore given schedule is cascade less schedule.
Special Case: A committed transaction desired to abort. As given below all the transactions are reading committed data hence it's cascadeless schedule.
A schedule is strict if it is both recoverable and cascadeless.
A strict schedule ensures strong data consistency by following two key rules:
This means that if a transaction fails before committing, all its changes must be undone (rolled back), and any other transactions that used its uncommitted data must also be rolled back.
Strict schedule helps in maintaining a reliable and consistent database by preventing data conflicts and minimizing errors.
Example:
S4: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), C1, W3(y), C3, R2(y), W2(z), W2(y), C2;
In this schedule, no read-write or write-write conflict arises before committing hence its strict schedule:
Cascading Abort: Cascading Abort can also be rollback. If transaction T1 aborts as T2 read data that is written by T1 it is not committed. Hence its cascading rollback.
Example:
In Database Management Systems (DBMS), the schedules can be categorized based on their recoverability. Recoverability refers to the ability to recover the database to a consistent state after a transaction failure.
