Distributed concurrency control - Revision history

PetraMagna: did not notice this part also needs to be removed due to OR/NPOV issues

2024-03-06T05:43:57Z

did not notice this part also needs to be removed due to OR/NPOV issues

← Previous revision		Revision as of 05:43, 6 March 2024
Line 4:		Line 4:
	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]).		In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'' and ''[[database transaction schedule#Strict\|strictness]]''. Strictness, a special case of recoverability, is utilized for effective recovery from failure. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system.		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'' and ''[[database transaction schedule#Strict\|strictness]]''. Strictness, a special case of recoverability, is utilized for effective recovery from failure. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]].

	==See also==		==See also==

PetraMagna: clean up NPOV issue with commitment ordering; there might still be some OR in the article

2024-03-06T02:46:53Z

clean up NPOV issue with commitment ordering; there might still be some OR in the article

← Previous revision		Revision as of 02:46, 6 March 2024
Line 2:		Line 2:
	'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).		'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).		In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[database transaction schedule#Strict\|strictness]]''~~, and ''commitment ordering'' properties~~. Strictness, a special case of recoverability, is utilized for effective recovery from failure~~, and commitment ordering allows participating in a general solution for global serializability~~. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'' and ''[[database transaction schedule#Strict\|strictness]]''. Strictness, a special case of recoverability, is utilized for effective recovery from failure. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system.

	==See also==		==See also==
Line 12:		Line 12:
	*<cite id=Bern87>[[Phil Bernstein\|Philip A. Bernstein]], Vassos Hadzilacos, Nathan Goodman (1987): [http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx ''Concurrency Control and Recovery in Database Systems''], Addison Wesley Publishing Company, 1987, {{ISBN\|0-201-10715-5}} </cite>		*<cite id=Bern87>[[Phil Bernstein\|Philip A. Bernstein]], Vassos Hadzilacos, Nathan Goodman (1987): [http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx ''Concurrency Control and Recovery in Database Systems''], Addison Wesley Publishing Company, 1987, {{ISBN\|0-201-10715-5}} </cite>
	*<cite id=Weikum01>[[Gerhard Weikum]], Gottfried Vossen (2001): [http://www.elsevier.com/wps/find/bookdescription.cws_home/677937/description#description ''Transactional Information Systems''], Elsevier, {{ISBN\|1-55860-508-8}} </cite>		*<cite id=Weikum01>[[Gerhard Weikum]], Gottfried Vossen (2001): [http://www.elsevier.com/wps/find/bookdescription.cws_home/677937/description#description ''Transactional Information Systems''], Elsevier, {{ISBN\|1-55860-508-8}} </cite>
	*<cite id=Raz92>[[Yoav Raz]] (1992): [https://web.archive.org/web/20070523182950/http://www.informatik.uni-trier.de/~ley/db/conf/vldb/Raz92.html "The Principle of Commitment Ordering, or Guaranteeing Serializability in a Heterogeneous Environment of Multiple Autonomous Resource Managers Using Atomic Commitment."] ''Proceedings of the Eighteenth International Conference on Very Large Data Bases'' (VLDB), pp. 292-312, Vancouver, Canada, August 1992. (also DEC-TR 841, [[Digital Equipment Corporation]], November 1990) </cite>

	[[Category:Data management]]		[[Category:Data management]]

Guy Harris: Avoid redirect.

2023-12-22T21:47:07Z

Avoid redirect.

← Previous revision		Revision as of 21:47, 22 December 2023
Line 4:		Line 4:
	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).		In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[~~schedule~~ ~~(computer~~ ~~science)~~#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[database transaction schedule#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).

	==See also==		==See also==

LicenceToCrenellate: WP:WTAF

2020-02-07T19:09:09Z

WP:WTAF

← Previous revision		Revision as of 19:09, 7 February 2020
Line 2:		Line 2:
	'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).		'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-[[transactional object]]) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).		In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).

Materialscientist: Reverted 1 good faith edit by 2409:4052:90D:1CD4:7819:E98F:C017:32B0 using STiki

2018-11-30T09:13:36Z

Reverted 1 good faith edit by 2409:4052:90D:1CD4:7819:E98F:C017:32B0 using STiki

← Previous revision		Revision as of 09:13, 30 November 2018
Line 5:		Line 5:

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).
	read_item() − reads data item from storage to main memory.

	modify_item() − change value of item in the main memory.

	write_item() − write the modified value from main memory to storage.

	==See also==		==See also==

2409:4052:90D:1CD4:7819:E98F:C017:32B0 at 07:42, 26 November 2018

2018-11-26T07:42:33Z

← Previous revision		Revision as of 07:42, 26 November 2018
Line 5:		Line 5:

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).
			read_item() − reads data item from storage to main memory.

			modify_item() − change value of item in the main memory.

			write_item() − write the modified value from main memory to storage.

	==See also==		==See also==

Flooded with them hundreds: Reverted edits by 2409:4052:90D:1CD4:7819:E98F:C017:32B0 (talk): unexplained content removal (HG) (3.4.4)

2018-11-26T07:40:58Z

Reverted edits by 2409:4052:90D:1CD4:7819:E98F:C017:32B0 (talk): unexplained content removal (HG) (3.4.4)

← Previous revision		Revision as of 07:40, 26 November 2018
Line 1:		Line 1:

			'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

			In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-[[transactional object]]) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).

			The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).

			==See also==
			*[[Global concurrency control]]

			==References==
			*<cite id=Bern87>[[Phil Bernstein\|Philip A. Bernstein]], Vassos Hadzilacos, Nathan Goodman (1987): [http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx ''Concurrency Control and Recovery in Database Systems''], Addison Wesley Publishing Company, 1987, {{ISBN\|0-201-10715-5}} </cite>
			*<cite id=Weikum01>[[Gerhard Weikum]], Gottfried Vossen (2001): [http://www.elsevier.com/wps/find/bookdescription.cws_home/677937/description#description ''Transactional Information Systems''], Elsevier, {{ISBN\|1-55860-508-8}} </cite>
			*<cite id=Raz92>[[Yoav Raz]] (1992): [https://web.archive.org/web/20070523182950/http://www.informatik.uni-trier.de/~ley/db/conf/vldb/Raz92.html "The Principle of Commitment Ordering, or Guaranteeing Serializability in a Heterogeneous Environment of Multiple Autonomous Resource Managers Using Atomic Commitment."] ''Proceedings of the Eighteenth International Conference on Very Large Data Bases'' (VLDB), pp. 292-312, Vancouver, Canada, August 1992. (also DEC-TR 841, [[Digital Equipment Corporation]], November 1990) </cite>

	[[Category:Data management]]		[[Category:Data management]]

2409:4052:90D:1CD4:7819:E98F:C017:32B0: ←Replaced content with ' Category:Data management Category:Distributed computing problems Category:Databases Category:Concurrency control Category:Transaction pro...'

2018-11-26T07:40:53Z

←Replaced content with ' Category:Data management Category:Distributed computing problems Category:Databases Category:Concurrency control Category:Transaction pro...'

← Previous revision		Revision as of 07:40, 26 November 2018
Line 1:		Line 1:

	on. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).

	==See also==
	*[[Global concurrency control]]

	==References==
	*<cite id=Bern87>[[Phil Bernstein\|Philip A. Bernstein]], Vassos Hadzilacos, Nathan Goodman (1987): [http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx ''Concurrency Control and Recovery in Database Systems''], Addison Wesley Publishing Company, 1987, {{ISBN\|0-201-10715-5}} </cite>
	*<cite id=Weikum01>[[Gerhard Weikum]], Gottfried Vossen (2001): [http://www.elsevier.com/wps/find/bookdescription.cws_home/677937/description#description ''Transactional Information Systems''], Elsevier, {{ISBN\|1-55860-508-8}} </cite>
	*<cite id=Raz92>[[Yoav Raz]] (1992): [https://web.archive.org/web/20070523182950/http://www.informatik.uni-trier.de/~ley/db/conf/vldb/Raz92.html "The Principle of Commitment Ordering, or Guaranteeing Serializability in a Heterogeneous Environment of Multiple Autonomous Resource Managers Using Atomic Commitment."] ''Proceedings of the Eighteenth International Conference on Very Large Data Bases'' (VLDB), pp. 292-312, Vancouver, Canada, August 1992. (also DEC-TR 841, [[Digital Equipment Corporation]], November 1990) </cite>

	[[Category:Data management]]		[[Category:Data management]]

2409:4052:90D:1CD4:7819:E98F:C017:32B0 at 07:40, 26 November 2018

2018-11-26T07:40:12Z

← Previous revision		Revision as of 07:40, 26 November 2018
Line 1:		Line 1:

			on. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).
	'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-[[transactional object]]) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).

	==See also==		==See also==

LWG: rm dead pov tag: no extant dispute

2018-01-05T19:58:43Z

rm dead pov tag: no extant dispute

← Previous revision		Revision as of 19:58, 5 January 2018
Line 1:		Line 1:

	{{POV\|Commitment ordering\|date=November 2011}}
	'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).		'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

← Previous revision		Revision as of 19:09, 7 February 2020
Line 2:		Line 2:
	'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).		'''Distributed concurrency control''' is the [[concurrency control]] of a system [[Distributed computing\|distributed]] over a [[computer network]] ([[#Bern87\|Bernstein et al. 1987]], [[#Weikum01\|Weikum and Vossen 2001]]).

	In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-[[transactional object]]) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).		In ''[[database systems]]'' and ''[[transaction processing]]'' (''transaction management'') distributed concurrency control refers primarily to the concurrency control of a [[distributed database]]. It also refers to the concurrency control in a multidatabase (and other multi-transactional object) environment (e.g., [[federated database]], [[grid computing]], and [[cloud computing]] environments. A major goal for distributed concurrency control is distributed [[serializability]] (or [[global serializability]] for multidatabase systems). Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer [[latency (engineering)\|latency]]. It often requires special techniques, like [[distributed lock manager]] over fast [[computer network]]s with low latency, like [[switched fabric]] (e.g., [[InfiniBand]]). [[Commitment ordering]] (or commit ordering) is a general serializability technique that achieves distributed serializability (and global serializability in particular) effectively on a large scale, without concurrency control information distribution (e.g., local precedence relations, locks, timestamps, or tickets), and thus without performance penalties that are typical to other serializability techniques ([[#Raz92\|Raz 1992]]).

	The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).		The most common distributed concurrency control technique is ''strong strict two-phase locking'' ([[two phase locking#Strong strict two-phase locking\|SS2PL]], also named ''rigorousness''), which is also a common centralized concurrency control technique. SS2PL provides both the ''serializability'', ''[[schedule (computer science)#Strict\|strictness]]'', and ''commitment ordering'' properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty (due to delays, latency) can be saved by using the [[atomic commitment]] protocol, which is needed in a distributed database for (distributed) transactions' [[Atomicity (database systems)\|atomicity]] (e.g., [[Two-phase commit protocol\|two-phase commit]], or a simpler one in a reliable system), together with some local commitment ordering variant (e.g., local [[two phase locking#Strong strict two-phase locking\|SS2PL]]) instead of distributed locking, to achieve global serializability in the entire system. All the commitment ordering theoretical results are applicable whenever atomic commitment is utilized over partitioned, distributed recoverable (transactional) data, including automatic ''distributed deadlock'' resolution. Such technique can be utilized also for a large-scale [[parallel database]], where a single large database, residing on many nodes and using a distributed lock manager, is replaced with a (homogeneous) multidatabase, comprising many relatively small databases (loosely defined; any process that supports transactions over partitioned data and participates in atomic commitment complies), fitting each into a single node, and using commitment ordering (e.g., SS2PL, strict CO) together with some appropriate atomic commitment protocol (without using a distributed lock manager).