Content deleted Content added
Undid revision 1236623893 by 217.197.97.50 to restore original meaning. The schedule is trivially recoverable since no transaction reads from another |
m →Cascadeless: Typo fixing, replaced: a.k.a, → a.k.a. |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 456:
====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:
|