Content deleted Content added
→Conflicting actions: Explained conflicting actions more thoroughly |
→Serializable: Included information from the serializability Wikipedia article |
||
Line 156:
|Com.
|}
Serializability is used to keep the data in the data item in a consistent state. Serializability is a property of a [[Database transaction schedule|transaction schedule]] (history). It is the major criterion for the correctness of concurrent transactions' schedule, and thus supported in all general purpose database systems. Schedules that are not serializable are likely to generate erroneous outcomes; which can be extremely harmful when dealing with money within banks.
If any specific order between some transactions is requested by an application, then it is enforced independently of the underlying serializability mechanisms. These mechanisms are typically indifferent to any specific order, and generate some unpredictable [[partial order]] that is typically compatible with multiple serial orders of these transactions. This partial order results from the scheduling orders of concurrent transactions' data access operations, which depend on many factors.
====Conflicting actions====
Line 216 ⟶ 219:
|}
====Commitment-
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.
Line 378 ⟶ 381:
Since determining whether a schedule is view-serializable is [[NP-complete]], view-serializability has little practical interest.{{citation needed|date=April 2015}}
==== Relaxed serializability ====
'''Relaxed serializability''' allows controlled serializability violations in order to achieve higher performance. Higher performance means better transaction execution rate and shorter average transaction response time (transaction duration). Relaxed serializability is used when absolute correctness is not needed from recently modified data (such as when retrieving a list of products). ''[[Snapshot isolation]]'' is a common relaxed serializability method.
Relaxing distributed serializability is often necessary for efficient large-scale data [[Replication (computer science)|replication]] because using a single atomic [[distributed transaction]] for synchronizing multiple replicas is likely to have unavailable [[Computer|computers]] and [[Computer network|networks]] which would cause aborts.<ref name="Gray1996">{{cite conference |author=Gray, J. |author-link=Jim Gray (computer scientist) |author2=Helland, P. |author3=O’Neil, P. |author3-link=Patrick O'Neil |author4=Shasha, D. |author4-link=Dennis Shasha |year=1996 |title=The dangers of replication and a solution |url=ftp://ftp.research.microsoft.com/pub/tr/tr-96-17.pdf |conference=Proceedings of the 1996 [[ACM SIGMOD International Conference on Management of Data]] |pages=173–182 |doi=10.1145/233269.233330}}{{dead link|date=May 2018|bot=InternetArchiveBot|fix-attempted=yes}}</ref> [[Optimistic replication]] is a common distributed serializability relaxation method which compromises [[eventual consistency]].
Classes of schedules defined by ''relaxed serializability'' properties either contain the serializability class, or are incomparable with it.
===Recoverable===<!-- This section is linked from [[Concurrency control]] -->
| |||