# What is the difference between “strict schedule” and “cascadeless schedule”?

In database transactions theory, what is the difference between a strict schedule and a schedule that is merely secured against cascade aborts?

Could you give an example of a schedule that is secured against cascade aborts but is not strict?

I found these slides that give definitions but it's still not clear to me where is the difference (they just seem differently worded).

On a cascadeless schedule a transaction $T_2$ cannot read a value $a$ if a transaction $T_1$ wrote $a$ before that and didn't commit. On a strict schedule $T_2$ also wouldn't be able to write $a$ after $T_1$ wrote it (even if it read $a$ before $T_1$ wrote it).

If you read carefully, the definition of strict says "not read or overwritten". That's the difference.

I reproduce here an example of cascadeless but not strict schedule, from the Wikipedia page on the subject:

• So blind writes are acceptable in Cascade-less schedule, right? – The Room Nov 8 '18 at 4:52
• It will not cause cascading aborts, so yes. – André Souza Lemos Nov 8 '18 at 5:46

Definitions from the books by Korth et. al. and Elmasri et al.:

A cascadeless schedule is one where, for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti , the commit operation of Ti appears before the read operation of Tj .

Strict schedule
If in the given schedule, each transaction Tj neither reads nor writes any data item ‘x’ until the last transaction Ti that has written ‘X’ is committed or aborted then it is strict.

Notice:

• Definition of cascadeless schedule only puts restriction on where in the schedule the reads of transaction Tj can appear.
• Definition of strict schedule only puts restriction on where in the schedule the reads and write of transaction Tj can appear.

Thus following schedule is allowed under cascadelessness definition but not under definition of strict schedule:

| T1       | T2       |
|----------|----------|
| write(x) |          |
|          | write(x) |
|          | commit   |


as write(x) of T1 appears before commit of T2. Evidently cascadeless schedule can contain blind writes !!!

Lets say T1 and T2 are two transactions. T1 is scheduled first and T2 next. Assume they gonna read a variable a

Now lets see how it works.