Content deleted Content added
No edit summary |
m →Cascadeless: Typo fixing, replaced: a.k.a, → a.k.a. |
||
(5 intermediate revisions by 3 users not shown) | |||
Line 452:
These schedules are recoverable. The schedule F is recoverable because T1 commits before T2, that makes the value read by T2 correct. Then T2 can commit itself. In the F2 schedule, if T1 aborted, T2 has to abort because the value of A it read is incorrect. In both cases, the database is left in a consistent state.
====Cascadeless====
'''Cascadeless schedules''' (a.k.a
The following examples are the same as the ones in the discussion on recoverable:
Line 535:
====Strict====
A schedule is '''strict''' if for any two transactions T1, T2, if a write operation of T1 precedes a ''conflicting'' operation of T2 (either read or write), then the commit or abort event of T1 also precedes that conflicting operation of T2. For example, the schedule F3 above is strict.
Any strict schedule is cascade-less, but not the converse. Strictness allows efficient recovery of databases from failure.
== Serializability
The following expressions illustrate the hierarchical (containment) relationships between [[serializability]] and [[Serializability#Correctness - recoverability|recoverability]] classes:
|