geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kmil...@apache.org
Subject [geode] branch develop updated: GEODE-5287 Incorporate ACID semantics into transaction intro docs (#2032)
Date Wed, 06 Jun 2018 20:32:40 GMT
This is an automated email from the ASF dual-hosted git repository.

kmiller pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/geode.git


The following commit(s) were added to refs/heads/develop by this push:
     new c9e7d88  GEODE-5287 Incorporate ACID semantics into transaction intro docs (#2032)
c9e7d88 is described below

commit c9e7d8879d30926e5cbbfc71e54b6a75055357c6
Author: Karen Miller <karensmolermiller@users.noreply.github.com>
AuthorDate: Wed Jun 6 13:32:31 2018 -0700

    GEODE-5287 Incorporate ACID semantics into transaction intro docs (#2032)
    
    * GEODE-5287 Incorporate ACID semantics into transaction intro docs
    
    * GEODE-5287 Implemented review suggestion and fixed a broken link
---
 .../source/subnavs/geode-subnav.erb                |  5 +--
 .../transactions/about_transactions.html.md.erb    | 37 ++++++++++++++-
 .../transactions/chapter_overview.html.md.erb      |  4 +-
 .../how_cache_transactions_work.html.md.erb        |  2 -
 .../transactions/transaction_semantics.html.md.erb | 52 ----------------------
 5 files changed, 39 insertions(+), 61 deletions(-)

diff --git a/geode-book/master_middleman/source/subnavs/geode-subnav.erb b/geode-book/master_middleman/source/subnavs/geode-subnav.erb
index c2c3cff..a37cbf6 100644
--- a/geode-book/master_middleman/source/subnavs/geode-subnav.erb
+++ b/geode-book/master_middleman/source/subnavs/geode-subnav.erb
@@ -1372,7 +1372,7 @@ limitations under the License.
                         <a href="/docs/guide/<%=vars.product_version_nodot%>/developing/transactions/chapter_overview.html">Transactions</a>
                         <ul>
                             <li>
-                                <a href="/docs/guide/<%=vars.product_version_nodot%>/developing/transactions/about_transactions.html">About
Transactions</a>
+                                <a href="/docs/guide/<%=vars.product_version_nodot%>/developing/transactions/about_transactions.html">Introduction
and the Application of ACID Semantics</a>
                             </li>
                             <li class="has_submenu">
                                 <a href="/docs/guide/<%=vars.product_version_nodot%>/developing/transactions/cache_transactions.html">Geode
Cache Transactions</a>
@@ -1481,9 +1481,6 @@ limitations under the License.
                                                     </li>
                                                 </ul>
                                             </li>
-                                            <li>
-                                                <a href="/docs/guide/<%=vars.product_version_nodot%>/developing/transactions/transaction_semantics.html">Geode
Cache Transaction Semantics</a>
-                                            </li>
                                         </ul>
                                     </li>
                                 </ul>
diff --git a/geode-docs/developing/transactions/about_transactions.html.md.erb b/geode-docs/developing/transactions/about_transactions.html.md.erb
index bc9e371..a0a9047 100644
--- a/geode-docs/developing/transactions/about_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/about_transactions.html.md.erb
@@ -1,5 +1,5 @@
 ---
-title: About Transactions
+title: Introduction and the Application of ACID Semantics
 ---
 
 <!--
@@ -45,3 +45,38 @@ JTA global transactions allow you to use the standard JTA interface to
coordinat
 You can also coordinate a <%=vars.product_name%> cache transaction with an external
database by specifying database operations within cache and transaction application plug-ins
(CacheWriters/CacheListeners and TransactionWriters/TransactionListeners.) This is an alternative
to using JTA transactions. See [How to Run a <%=vars.product_name%> Cache Transaction
that Coordinates with an External Database](run_a_cache_transaction_with_external_db.html#task_sdn_2qk_2l).
 
 
+## Application of ACID Semantics
+
+<%=vars.product_name%> transaction semantics differ in some ways from the Atomicity-Consistency-Isolation-Durability
(ACID) semantics of traditional relational databases. For performance reasons, <%=vars.product_name%>
transactions do not adhere to ACID constraints by default, but can be configured for ACID
support as described in this section.
+
+### <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.
+
+<%=vars.product_name%> 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.  [...]
+
+### <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 assures that operations will see either the pre-transaction state of the system
or its post-transaction state, but not the transitional state that occurs while a transaction
is in progress. Write operations in a transaction are always confirmed to ensure that stale
values are not written. As a distributed cache-based system optimized for performance, <%=vars.product_name%>
in its default configuration does not enforce read isolation. <%=vars.product_name%>
transactions support  [...]
+
+In the default configuration, <%=vars.product_name%> isolates transactions at the process
thread level, so while a transaction is in progress, its changes are visible only inside the
thread that is running the transaction. Threads inside the same process and in other processes
cannot see changes until after the commit operation begins. At this point, the changes are
visible in the cache, but other threads that access the changing data might see only partial
results of the transaction lea [...]
+
+If an application requires the slower conventional isolation model (such that dirty reads
of transitional states are not allowed), read operations must be encapsulated within transactions
and the `gemfire.detectReadConflicts` parameter must be set to ‘true’:
+
+`-Dgemfire.detectReadConflicts=true`
+
+This parameter causes read operations to succeed only when they read a consistent pre- or
post-transactional state. If not, a `CommitConflictException` is thrown to the calling application.
+
+### <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. As a distributed cache-based system optimized for performance, <%=vars.product_name%>
does not support on-disk or in-memory durability for transactions.
+
+Applications can emulate the conventional disk-based durability model by setting the `gemfire.ALLOW_PERSISTENT_TRANSACTIONS`
parameter to ‘true’.
+
+`-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true`
+
+This allows permanent regions to participate in transactions, thus providing disk-based durability.
See [Transactions and Persistent Regions](cache_transactions_by_region_type.html#concept_omy_341_wk)
for more detail on the use of this parameter.
diff --git a/geode-docs/developing/transactions/chapter_overview.html.md.erb b/geode-docs/developing/transactions/chapter_overview.html.md.erb
index 0f2dc37..ae85405 100644
--- a/geode-docs/developing/transactions/chapter_overview.html.md.erb
+++ b/geode-docs/developing/transactions/chapter_overview.html.md.erb
@@ -21,9 +21,9 @@ limitations under the License.
 
 <%=vars.product_name%> provides a transactions API, with `begin`, `commit`, and `rollback`
methods. These methods are much the same as the familiar relational database transactions
methods.
 
--   **[About Transactions](about_transactions.html)**
+-   **[Introduction and the Application of ACID Semantics](about_transactions.html)**
 
-    This section covers the features of <%=vars.product_name%> transactions.
+    This section presents the features of <%=vars.product_name%> transactions and discusses
how the implementation adheres to ACID semantics.
 It also details the two kinds of transaction that <%=vars.product_name%> supports:
 **<%=vars.product_name%> cache transactions** and **JTA global transactions**.
 
diff --git a/geode-docs/developing/transactions/how_cache_transactions_work.html.md.erb b/geode-docs/developing/transactions/how_cache_transactions_work.html.md.erb
index c7bca5b..a72cce7 100644
--- a/geode-docs/developing/transactions/how_cache_transactions_work.html.md.erb
+++ b/geode-docs/developing/transactions/how_cache_transactions_work.html.md.erb
@@ -33,8 +33,6 @@ All the regions in a <%=vars.product_name%> member cache can participate
in a tr
 
 -   **[Comparing Transactional and Non-Transactional Operations](transactional_and_nontransactional_ops.html#transactional_and_nontransactional_ops)**
 
--   **[<%=vars.product_name%> Cache Transaction Semantics](transaction_semantics.html)**
-
 ## Transaction View
 
 A transaction is isolated from changes made concurrently to the cache. Each transaction has
its own private view of the cache, including the entries it has read and the changes it has
made. The first time the transaction touches an entry in the cache, either to read or write,
it produces a snapshot of that entry’s state in the transaction’s view. The transaction
maintains its current view of the entry, which reflects only the changes made within the transaction.
The transaction remembers [...]
diff --git a/geode-docs/developing/transactions/transaction_semantics.html.md.erb b/geode-docs/developing/transactions/transaction_semantics.html.md.erb
deleted file mode 100644
index 3df3f20..0000000
--- a/geode-docs/developing/transactions/transaction_semantics.html.md.erb
+++ /dev/null
@@ -1,52 +0,0 @@
-<% set_title(product_name, "Cache Transaction Semantics") %>
-
-<!--
-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.
--->
-
-<%=vars.product_name%> transaction semantics differ in some ways from the Atomicity-Consistency-Isolation-Durability
(ACID) semantics of traditional relational databases. For performance reasons, <%=vars.product_name%>
transactions do not adhere to ACID constraints by default, but can be configured for ACID
support as described in this section.
-
-## <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.
-
-<%=vars.product_name%> 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.  [...]
-
-## <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 assures that operations will see either the pre-transaction state of the system
or its post-transaction state, but not the transitional state that occurs while a transaction
is in progress. Write operations in a transaction are always confirmed to ensure that stale
values are not written. As a distributed cache-based system optimized for performance, <%=vars.product_name%>
in its default configuration does not enforce read isolation. <%=vars.product_name%>
transactions support  [...]
-
-In the default configuration, <%=vars.product_name%> isolates transactions at the process
thread level, so while a transaction is in progress, its changes are visible only inside the
thread that is running the transaction. Threads inside the same process and in other processes
cannot see changes until after the commit operation begins. At this point, the changes are
visible in the cache, but other threads that access the changing data might see only partial
results of the transaction lea [...]
-
-If an application requires the slower conventional isolation model (such that dirty reads
of transitional states are not allowed), read operations must be encapsulated within transactions
and the `gemfire.detectReadConflicts` parameter must be set to ‘true’:
-
-`-Dgemfire.detectReadConflicts=true`
-
-This parameter causes read operations to succeed only when they read a consistent pre- or
post-transactional state. If not, a `CommitConflictException` is thrown to the calling application.
-
-## <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. As a distributed cache-based system optimized for performance, <%=vars.product_name%>
does not support on-disk or in-memory durability for transactions.
-
-Applications can emulate the conventional disk-based durability model by setting the `gemfire.ALLOW_PERSISTENT_TRANSACTIONS`
parameter to ‘true’.
-
-`-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true`
-
-This allows permanent regions to participate in transactions, thus providing disk-based durability.
See [Transactions and Persistent Regions](cache_transactions_by_region_type.html#concept_omy_341_wk)
for more detail on the use of this parameter.

-- 
To stop receiving notification emails like this one, please contact
kmiller@apache.org.

Mime
View raw message