Content deleted Content added
→Duration: Changed and merged headings to redistribute the information |
→Serializable: rephrased some sentences to be more clear |
||
Line 77:
===Serial===
Schedule D is an example of a serial schedule:
Line 125:
===Serializable===<!-- This section is linked from [[Concurrency control]] -->
A schedule
In schedule E, the order in which the actions of the transactions are executed is not the same as in D, but in the end, E gives the same result as D.
Line 202:
====Conflict-serializable====
A schedule is said to be '''conflict-serializable''' when the schedule is conflict-equivalent to one or more serial schedules.
Equivalently, a schedule is conflict-serializable if and only if its [[precedence graph]] is acyclic when only committed transactions are considered. Note that if the graph is defined to also include uncommitted transactions, then cycles involving uncommitted transactions may occur without conflict serializability violation.
Line 237:
A schedule is said to be commitment-ordered (commit-ordered), or commitment-order-serializable, if it obeys the [[Commitment ordering]] (CO; also commit-ordering or commit-order-serializability) schedule property. This means that the order in time of transactions' commitment events is compatible with the precedence (partial) order of the respective transactions, as induced by their schedule's acyclic precedence graph (serializability graph, conflict graph). This implies that it is also conflict-serializable. The CO property is especially effective for achieving [[Global serializability]] in distributed systems.
====View equivalence====
|