geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zho...@apache.org
Subject [03/11] geode git commit: GEODE-3395 Variable-ize product version and name in user guide - Developing
Date Fri, 18 Aug 2017 23:10:24 GMT
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/working_with_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/working_with_transactions.html.md.erb b/geode-docs/developing/transactions/working_with_transactions.html.md.erb
index 4a26d4c..d75f6ad 100644
--- a/geode-docs/developing/transactions/working_with_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/working_with_transactions.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Working with Geode Cache Transactions
----
+<% set_title("Working with", product_name, "Cache Transactions") %>
 
 <!--
 Licensed to the Apache Software Foundation (ASF) under one or more
@@ -21,7 +19,7 @@ limitations under the License.
 <a id="topic_tx2_gs4_5k"></a>
 
 
-This section contains guidelines and additional information on working with Geode and its
cache transactions.
+This section contains guidelines and additional information on working with <%=vars.product_name%>
and its cache transactions.
 
 -   **[Setting Global Copy on Read](#concept_vx2_gs4_5k)**
 
@@ -134,13 +132,13 @@ Local expiration actions do not cause write conflicts, but distributed
expiratio
 
 A transaction that modifies a region in which consistency checking is enabled generates all
necessary version information for region updates when the transaction commits.
 
-If a transaction modifies a normal, preloaded or empty region, the transaction is first delegated
to a Geode member that holds a replicate for the region. This behavior is similar to the transactional
behavior for partitioned regions, where the partitioned region transaction is forwarded to
a member that hosts the primary for the partitioned region update.
+If a transaction modifies a normal, preloaded or empty region, the transaction is first delegated
to a <%=vars.product_name%> member that holds a replicate for the region. This behavior
is similar to the transactional behavior for partitioned regions, where the partitioned region
transaction is forwarded to a member that hosts the primary for the partitioned region update.
 
-The limitation for transactions with a normal, preloaded or empty region is that, when consistency
checking is enabled, a transaction cannot perform a `localDestroy` or `localInvalidate` operation
against the region. Geode throws an `UnsupportedOperationInTransactionException` exception
in such cases. An application should use a `Destroy` or `Invalidate` operation in place of
a `localDestroy` or `localInvalidate` when consistency checks are enabled.
+The limitation for transactions with a normal, preloaded or empty region is that, when consistency
checking is enabled, a transaction cannot perform a `localDestroy` or `localInvalidate` operation
against the region. <%=vars.product_name%> throws an `UnsupportedOperationInTransactionException`
exception in such cases. An application should use a `Destroy` or `Invalidate` operation in
place of a `localDestroy` or `localInvalidate` when consistency checks are enabled.
 
 ## Suspending and Resuming Transactions
 
-The Geode `CacheTransactionManager` API provides the ability to suspend and resume transactions
with the `suspend` and `resume` methods. The ability to suspend and resume is useful when
a thread must perform some operations that should not be part of the transaction before the
transaction can complete. A complex use case of suspend and resume implements a transaction
that spans clients in which only one client at a time will not be suspended.
+The <%=vars.product_name%> `CacheTransactionManager` API provides the ability to suspend
and resume transactions with the `suspend` and `resume` methods. The ability to suspend and
resume is useful when a thread must perform some operations that should not be part of the
transaction before the transaction can complete. A complex use case of suspend and resume
implements a transaction that spans clients in which only one client at a time will not be
suspended.
 
 Once a transaction is suspended, it loses the transactional view of the cache. None of the
operations done within the transaction are visible to the thread. Any operations that are
performed by the thread while the transaction is suspended are not part of the transaction.
 
@@ -150,17 +148,17 @@ Before resuming a transaction, you may want to check if the transaction
exists o
 
 If the member with the primary copy of the data crashes, the transactional view associated
with that data is lost. The secondary member for the data will not be able to resume any transactions
suspended on the crashed member. You will need to take remedial steps to retry the transaction
on a new primary copy of the data.
 
-If a suspended transaction is not touched for a period of time, Geode cleans it up automatically.
By default, the timeout for a suspended transaction is 30 minutes and can be configured using
the system property `gemfire.suspendedtxTimeout`. For example, `gemfire.suspendedtxTimeout=60`
specifies a timeout of 60 minutes.
+If a suspended transaction is not touched for a period of time, <%=vars.product_name%>
cleans it up automatically. By default, the timeout for a suspended transaction is 30 minutes
and can be configured using the system property `gemfire.suspendedtxTimeout`. For example,
`gemfire.suspendedtxTimeout=60` specifies a timeout of 60 minutes.
 
 See [Basic Suspend and Resume Transaction Example](transaction_suspend_resume_example.html)
for a sample code fragment that suspends and resumes a transaction.
 
 ## Using Cache Writer and Cache Listener Plug-Ins
 
-All standard Geode application plug-ins work with transactions. In addition, the transaction
interface offers specialized plug-ins that support transactional operation.
+All standard <%=vars.product_name%> application plug-ins work with transactions. In
addition, the transaction interface offers specialized plug-ins that support transactional
operation.
 
-No direct interaction exists between client transactions and client application plug-ins.
When a client runs a transaction, Geode calls the plug-ins that are installed on the transaction's
server delegate and its server host. Client application plug-ins are not called for operations
inside the transaction or for the transaction as a whole. When the transaction is committed,
the changes to the server cache are sent to the client cache according to client interest
registration. These events can result in calls to the client's `CacheListener`s, as with any
other events received from the server.
+No direct interaction exists between client transactions and client application plug-ins.
When a client runs a transaction, <%=vars.product_name%> calls the plug-ins that are
installed on the transaction's server delegate and its server host. Client application plug-ins
are not called for operations inside the transaction or for the transaction as a whole. When
the transaction is committed, the changes to the server cache are sent to the client cache
according to client interest registration. These events can result in calls to the client's
`CacheListener`s, as with any other events received from the server.
 
-The `EntryEvent` that a callback receives has a unique Geode transaction ID, so the cache
listener can associate each event, as it occurs, with a particular transaction. The transaction
ID of an `EntryEvent` that is not part of a transaction is null to distinguish it from a transaction
ID.
+The `EntryEvent` that a callback receives has a unique <%=vars.product_name%> transaction
ID, so the cache listener can associate each event, as it occurs, with a particular transaction.
The transaction ID of an `EntryEvent` that is not part of a transaction is null to distinguish
it from a transaction ID.
 
 -   `CacheLoader`. When a cache loader is called by a transaction operation, values loaded
by the cache loader may cause a write conflict when the transaction commits.
 -   `CacheWriter`. During a transaction, if a cache writer exists, its methods are invoked
as usual for all operations, as the operations are called in the transactions. The `netWrite`
operation is not used. The only cache writer used is the one in the member where the transactional
data resides.
@@ -170,9 +168,9 @@ For more information on writing cache event handlers, see [Implementing
Cache Ev
 
 ## <a id="concept_ocw_vf1_wk" class="no-quick-link"></a>Configuring Transaction
Plug-In Event Handlers
 
-Geode has two types of transaction plug-ins: Transaction Writers and Transaction Listeners.
You can optionally install one transaction writer and one or more transaction listeners per
cache.
+<%=vars.product_name%> has two types of transaction plug-ins: Transaction Writers and
Transaction Listeners. You can optionally install one transaction writer and one or more transaction
listeners per cache.
 
-Like JTA global transactions, you can use transaction plug-in event handlers to coordinate
Geode cache transaction activity with an external data store. However, you typically use JTA
global transactions when Geode is running as a peer data store with your external data stores.
Transaction writers and listeners are typically used when Geode is acting as a front end cache
to your backend database.
+Like JTA global transactions, you can use transaction plug-in event handlers to coordinate
<%=vars.product_name%> cache transaction activity with an external data store. However,
you typically use JTA global transactions when <%=vars.product_name%> is running as
a peer data store with your external data stores. Transaction writers and listeners are typically
used when <%=vars.product_name%> is acting as a front end cache to your backend database.
 
 **Note:**
 You can also use transaction plug-in event handlers when running JTA global transactions.
@@ -181,7 +179,7 @@ You can also use transaction plug-in event handlers when running JTA global
tran
 
 When you commit a transaction, if a transaction writer is installed in the cache where the
data updates were performed, it is called. The writer can do whatever work you need, including
aborting the transaction.
 
-The transaction writer is the last place that an application can rollback a transaction.
If the transaction writer throws any exception, the transaction is rolled back. For example,
you might use a transaction writer to update a backend data source before the Geode cache
transaction completes the commit. If the backend data source update fails, the transaction
writer implementation can throw a [TransactionWriterException](/releases/latest/javadoc/org/apache/geode/cache/TransactionWriterException.html)
to veto the transaction.
+The transaction writer is the last place that an application can rollback a transaction.
If the transaction writer throws any exception, the transaction is rolled back. For example,
you might use a transaction writer to update a backend data source before the <%=vars.product_name%>
cache transaction completes the commit. If the backend data source update fails, the transaction
writer implementation can throw a [TransactionWriterException](/releases/latest/javadoc/org/apache/geode/cache/TransactionWriterException.html)
to veto the transaction.
 
 A typical usage scenario would be to use the transaction writer to prepare the commit on
the external database. Then in a transaction listener, you can apply the commit on the database.
 
@@ -193,7 +191,7 @@ Transaction listeners have access to the transactional view and thus are
not aff
 
 A transaction listener can preserve the result of a transaction, perhaps to compare with
other transactions, or for reference in case of a failed commit. When a commit fails and the
transaction ends, the application cannot just retry the transaction, but must build up the
data again. For most applications, the most efficient action is just to start a new transaction
and go back through the application logic again.
 
-The rollback and failed commit operations are local to the member where the transactional
operations are run. When a successful commit writes to a distributed or partitioned region,
however, the transaction results are distributed to other members the same as other updates.
The transaction listener on the receiving members reflect the changes the transaction makes
in that member, not the originating member. Any exceptions thrown by the transaction listener
are caught by Geode and logged.
+The rollback and failed commit operations are local to the member where the transactional
operations are run. When a successful commit writes to a distributed or partitioned region,
however, the transaction results are distributed to other members the same as other updates.
The transaction listener on the receiving members reflect the changes the transaction makes
in that member, not the originating member. Any exceptions thrown by the transaction listener
are caught by <%=vars.product_name%> and logged.
 
 To configure a transaction listener, add a `cache-transaction-manager` configuration to the
cache definition and define one or more instances of `transaction-listener` there. The only
parameter to this `transaction-listener` is `URL`, which must be a string, as shown in the
following cache.xml example.
 


Mime
View raw message