Database transaction schedule: Difference between revisions

Revision as of 07:41, 26 February 2024

Revision as of 07:16, 5 March 2024

Line 232:

|}

Conflict serializability can be enforced by restarting any transaction within the cycle in the precedence graph, or by implementing [[two-phase locking]], [[Timestamp-based concurrency control|timestamp ordering]], or [[Snapshot isolation#Workarounds|serializable snapshot isolation]].<ref name="Cahill082">Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008): [http://portal.acm.org/citation.cfm?id=1376690 "Serializable isolation for snapshot databases"], ''Proceedings of the 2008 ACM SIGMOD international conference on Management of data'', pp. 729-738, Vancouver, Canada, June 2008, {{ISBN|978-1-60558-102-6}} (SIGMOD 2008 best paper award)</ref>

==== Commitment-order-serializable ====

{{main|Commitment ordering}}

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.

[[Commitment ordering]], which was discovered in 1990, is obviously not mentioned in ([[#Bern1987|Bernstein et al. 1987]]). Its correct definition appears in ([[#Weikum2001|Weikum and Vossen 2001]]), however the description thereof its related techniques and theory is partial, inaccurate, and misleading.{{According to whom|date=December 2011}} For an extensive coverage of commitment ordering and its sources see ''[[Commitment ordering]]'' and ''[[The History of Commitment Ordering]]''.

====View equivalence====