geode-docs/developing/transactions/transactions_intro.html.md.erb - geode - Git at Google

 ---
 title: Adherence to ACID Promises
 ---

 <!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
 -->

 <a id="ACID"></a>

 This section introduces <%=vars.product_name%> transactions.
 <%=vars.product_name%> offers an API for client applications
 that do transactional work.
 <%=vars.product_name%> implements optimistic transactions,
 choosing the much higher transaction performance they offer over the slow,
 locking methods of a traditional relational database.

 Optimistic transaction semantics are not
 identical to the Atomicity-Consistency-Isolation-Durability (ACID) semantics
 of a traditional relational database.

 ### <a id="transaction_semantics__section_8362ACD06C784B5BBB0B7E986F760169" class="no-quick-link"></a>Atomicity

 Atomicity is “all or nothing” behavior: a transaction completes successfully only when all of the operations it contains complete successfully. If problems occur during a transaction, perhaps due to other transactions with overlapping changes, the transaction cannot successfully complete until the problems are resolved.

 Optimistic transactions provide atomicity and realize speed by using a reservation system, instead of using the traditional relational database technique of a two-phase locking of rows. The reservation prevents other, intersecting transactions from completing, allowing the commit to check for conflicts and to reserve resources in an all-or-nothing fashion prior to making changes to the data. After all changes have been made, locally and remotely, the reservation is released. With the reservation system, an intersecting transaction is simply discarded. The serialization of obtaining locks is avoided.

 ### <a id="transaction_semantics__section_7C287DA4A5134780B3199CE074E3F890" class="no-quick-link"></a>Consistency

 Consistency requires that data written within a transaction must observe the key and value constraints established for the affected region. Note that validity of the transaction is the responsibility of the application.

 ### <a id="transaction_semantics__section_126A24EC499D4CF39AE766A0B526A9A5" class="no-quick-link"></a>Isolation

 Isolation is the level at which transactional state is
 visible to system components.
 <%=vars.product_name%> transactions have repeatable read isolation.
 Once the committed value is read for a given key,
 it always returns that same value.
 If a write within a transaction
 deletes a value for a key that has already been read,
 subsequent reads return the transactional reference.

 The default configuration isolates transactions at the process thread level.
 While a transaction is in progress,
 its changes are visible only inside the thread that is running the transaction.
 Other threads within that same process and threads in other processes
 cannot see changes until after the commit operation begins.
 After beginning the commit, the changes are visible in the cache,
 but other threads that access the changing data might see partial results
 of the transaction, leading to a dirty read.
 See [Changing the Handling of Dirty Reads](design_considerations.html#transactions-dirty-reads) for how to change the default behavior.

 ### <a id="transaction_semantics__section_F092E368724945BCBF8E5DCB36B97EB4" class="no-quick-link"></a>Durability

 Relational databases provide durability by using disk storage for
 recovery and transaction logging.
 <%=vars.product_name%> is optimized for performance
 and does not support on-disk durability for transactions.

 See [Allowing Transactions to Work on Persistent Regions](design_considerations.html#transactions-persistence)
 for how to allow a transaction that operates on a persistent region
 in a non-durable way.
	---
	title: Adherence to ACID Promises
	---

	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	<a id="ACID"></a>

	This section introduces <%=vars.product_name%> transactions.
	<%=vars.product_name%> offers an API for client applications
	that do transactional work.
	<%=vars.product_name%> implements optimistic transactions,
	choosing the much higher transaction performance they offer over the slow,
	locking methods of a traditional relational database.

	Optimistic transaction semantics are not
	identical to the Atomicity-Consistency-Isolation-Durability (ACID) semantics
	of a traditional relational database.

	### <a id="transaction_semantics__section_8362ACD06C784B5BBB0B7E986F760169" class="no-quick-link"></a>Atomicity

	Atomicity is “all or nothing” behavior: a transaction completes successfully only when all of the operations it contains complete successfully. If problems occur during a transaction, perhaps due to other transactions with overlapping changes, the transaction cannot successfully complete until the problems are resolved.

	Optimistic transactions provide atomicity and realize speed by using a reservation system, instead of using the traditional relational database technique of a two-phase locking of rows. The reservation prevents other, intersecting transactions from completing, allowing the commit to check for conflicts and to reserve resources in an all-or-nothing fashion prior to making changes to the data. After all changes have been made, locally and remotely, the reservation is released. With the reservation system, an intersecting transaction is simply discarded. The serialization of obtaining locks is avoided.

	### <a id="transaction_semantics__section_7C287DA4A5134780B3199CE074E3F890" class="no-quick-link"></a>Consistency

	Consistency requires that data written within a transaction must observe the key and value constraints established for the affected region. Note that validity of the transaction is the responsibility of the application.

	### <a id="transaction_semantics__section_126A24EC499D4CF39AE766A0B526A9A5" class="no-quick-link"></a>Isolation

	Isolation is the level at which transactional state is
	visible to system components.
	<%=vars.product_name%> transactions have repeatable read isolation.
	Once the committed value is read for a given key,
	it always returns that same value.
	If a write within a transaction
	deletes a value for a key that has already been read,
	subsequent reads return the transactional reference.

	The default configuration isolates transactions at the process thread level.
	While a transaction is in progress,
	its changes are visible only inside the thread that is running the transaction.
	Other threads within that same process and threads in other processes
	cannot see changes until after the commit operation begins.
	After beginning the commit, the changes are visible in the cache,
	but other threads that access the changing data might see partial results
	of the transaction, leading to a dirty read.
	See [Changing the Handling of Dirty Reads](design_considerations.html#transactions-dirty-reads) for how to change the default behavior.

	### <a id="transaction_semantics__section_F092E368724945BCBF8E5DCB36B97EB4" class="no-quick-link"></a>Durability

	Relational databases provide durability by using disk storage for
	recovery and transaction logging.
	<%=vars.product_name%> is optimized for performance
	and does not support on-disk durability for transactions.

	See [Allowing Transactions to Work on Persistent Regions](design_considerations.html#transactions-persistence)
	for how to allow a transaction that operates on a persistent region
	in a non-durable way.