Cascading rollback – a single transaction failure leads to a series of transaction rollbacks.Hence database must ensure that schedules are recoverable. The following schedule (Schedule 11) is not recoverable if T9 commits immediately after the read T8 T9 read(A) write(A) read(A) read(B) If T8 should abort, T9 would have read (and possibly shown to the user) an inconsistent database state.Recoverable schedule - if a transaction Tj reads a data items previously written by a transaction Ti, the commit operation of Ti appears before the commit operation of Tj.Need to address the effect of transaction failures on concurrently running transactions. Determining such equivalence requires analysis of operations other than read and write.Schedule 8 (from text) given below produces same outcome as the serial schedule, yet is not conflict equivalent or view equivalent to it.Every view serializable schedule which is not conflict serializable has blind writes.T3 T4 T6 read(Q) write(Q) write(Q) write(Q)
Schedule 9 (from text) - a schedule which is view-serializable but not conflict serializable.Every conflict serializable schedule is also view serializable.A schedule S is view serializable if it is view equivalent to a serial schedule.As can be seen, view equivalence is also based purely on reads and writes alone.For each data item Q, the transaction (if any) that performs the final write(Q) operation in schedule S must perform the final write(Q) operation in schedule S 0. For each data item Q, if transaction Ti executes read(Q) in schedule S, and that value was produced by transaction Tj (if any), then transaction Ti must in schedule S 0 also read the value of Q that was produced by transaction Tj. For each data item Q, if transaction Ti reads the initial value of Q in schedule S, then transaction Ti must, in schedule S 0, also read the initial value of Q. S and S 0 are view equivalent if the following three conditions are met: 1. Let S and S 0 be two schedules with the same set of transactions.Therefore Schedule 3 is conflict serializable. Schedule 3 below can be transformed into Schedule 1, a serial schedule where T2 follows T1, by a series of swaps of non-conflicting instructions.We are unable to swap instructions in the above schedule to obtain either the serial schedule, or the serial schedule. Example of a schedule that is not conflict serializable : T3 T4 read(Q) write(Q) write(Q).We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule.If a schedule S can be transformed into a schedule S 0 by a series of swaps of non-conflicting instructions, we say that S and S 0 are conflict equivalent.If Ii and Ij are consecutive in a schedule and they do not conflict, their results would remain the same even if they had been interchanged in the schedule. Intuitively, a conflict between Ii and Ij forces a (logical) temporal order between them.Instructions Ii and Ij, of transactions Ti and Tj respectively, conflict if and only if there exists some item Q accessed by both Ii and Ij, and at least one of these instructions wrote Q.Our simplified schedules consist of only read and write instructions.
We ignore operations other than read and write instructions, and we assume that transactions may perform arbitrary computations on data in local buffers in between reads and writes.Different forms of schedule equivalence gives rise to the notions of : 1. A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.Thus serial execution of a set of transactions preserves database consistency.Basic Assumption – Each transaction preserves database consistency.