Database transaction schedule: Difference between revisions

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,. "Avoiding Cascading Aborts (ACA) schedules") are schedules which avoid cascading aborts by disallowing [[Write–read conflict|dirty reads]]. '''Cascading aborts''' occur when one transaction's abort causes another transaction to abort because it read and relied on the first transaction's changes to an object. A '''dirty read''' occurs when a transaction reads data from uncommitted write in another transaction.<ref>{{Cite web |date=2019-08-06 |title=Cascadeless in DBMS |url=https://www.geeksforgeeks.org/cascadeless-in-dbms/ |access-date=2023-11-29 |website=GeeksforGeeks |language=en-US}}</ref>
 
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 Classclass Relationshipsrelationships ==
 
The following expressions illustrate the hierarchical (containment) relationships between [[serializability]] and [[Serializability#Correctness - recoverability|recoverability]] classes: