Page History

...

T1 = r1[x] r1[z] w1[x] c1, T2 = r2[y] r2[z] w2[y] c2, T3 = w3[x] r3[y] w3[z] c3

...

S2 = w3[x] r1[x] r3[y] r2[y] w3[z] r2[z] r1[z] w2[y] w1[x] c1 c2 c3

The S1 is obviously serial: it corresponds to execution sequence: T3, T2, T1

What we can tell about serializability of S2 ? Recall the serializable schedule definition: to be serializable, it must be equivalent to some serial execution order of transactions T1, T2, T3. It's not obviuos if it is or not, because S2 has conflicting operations.

Two actions on the same data object, modified by different transactions, conflict, if at least one of them is a write. The three anomalous situations can be described in terms of when the actions of two transactions T1 and T2 conflict with each other: in a write-read (WR) conflict T2 reads a data object previously written by T1; we define read-write (RW) and write-write (WW) conflicts similarly. These conflicts cause various anomalies , like dirty reads, unrepeatable reads, lost updates, and other.

The S1 is obviously serial: it corresponds to execution sequence: T3, T2, T1. It's not that obvious for S2 if it's serializable or not. To prove it me should find a equivalent serializable schedule.

We must also take into account schedules containing aborted transactions. 

Consider two transactions

T1 = w1[x] a1, T2 = r2[x] w2[x] c2

and a schedule

w1[x] r2[x] w2[x] c2 a1

Such schedule is unrecoverable, because T2 is committed and can't be undone on T1 abort.

T1 = w1[x] c1, T2 = w2[x] a2

w2[x] w1[x] a2 c1

Here w1[x] will be undone by a2, causing lost update on c1.

Such schedules can be unrecoverable: assume some transaction depends on a data, modified by another transaction and it was committed, but another transaction was aborted. For a schedule to be recoverable, it's necessary to read only committed data. Recoverable schedules also avoid cascading aborts.

...