Database transaction schedule: Difference between revisions

Content deleted Content added
Hierarchical relationship between serializability classes: removed OR and NPOV issues related to commitment ordering; see WP:Articles for deletion/Commitment ordering.
Line 3:
{{more citations needed|date=November 2012}}
 
In the fields of [[database]]s and [[transaction processing]] (transaction management), a '''schedule''' (or '''history''') of a system is an abstract model to describe [[Execution (computing)|execution]] of transactions running in the system. Often it is a ''list'' of operations (actions) ordered by time, performed by a set of [[Database transaction|transactions]] that are executed together in the system. If the order in time between certain operations is not determined by the system, then a ''[[partial order]]'' is used. Examples of such operations are requesting a read operation, reading, writing, aborting, [[Commit (data management)|committing]], requesting a [[Lock (computer science)|lock]], locking, etc. Not all transaction operation types should be included in a schedule, and typically only selected operation types (e.g., data access operations) are included, as needed to reason about and describe certain phenomena. Schedules and schedule properties are fundamental concepts in database [[concurrency control]] theory. A schedule describes the order of actions of the transactions as seen by the [[DBMS]]. In practice, most general purpose database systems employ conflict-serializable and recoverable (primarily strict) schedules.
 
==Notation==
Line 541:
Any strict schedule is cascade-less, but not the converse. Strictness allows efficient recovery of databases from failure.
 
== Serializability Class Relationships ==
==Hierarchical relationship between serializability classes==
 
The following expressions illustrate the hierarchical (containment) relationships between [[serializability]] and [[Serializability#Correctness - recoverability|recoverability]] classes:
Line 551:
 
[[File:Schedule-serializability.png|frame|none|Venn diagram for serializability and recoverability classes]]
 
==Practical implementations==
 
In practice, most general purpose database systems employ conflict-serializable and recoverable (primarily strict) schedules.
 
==See also==