You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by zh...@apache.org on 2017/08/18 23:10:25 UTC
[04/11] geode git commit: GEODE-3395 Variable-ize product version and
name in user guide - Developing
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/JTA_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/JTA_transactions.html.md.erb b/geode-docs/developing/transactions/JTA_transactions.html.md.erb
index ffb6082..0dcc4fe 100644
--- a/geode-docs/developing/transactions/JTA_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/JTA_transactions.html.md.erb
@@ -1,6 +1,4 @@
----
-title: JTA Global Transactions with Geode
----
+<% set_title("JTA Global Transactions with", product_name) %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -20,42 +18,42 @@ limitations under the License.
-->
-Use JTA global transactions to coordinate Geode cache transactions and JDBC transactions.
+Use JTA global transactions to coordinate <%=vars.product_name%> cache transactions and JDBC transactions.
-JTA is a standard Java interface you can use to coordinate Geode cache transactions and JDBC transactions globally under one umbrella. JTA provides direct coordination between the Geode cache and another transactional resource, such as a database. The parties involved in a JTA transaction include:
+JTA is a standard Java interface you can use to coordinate <%=vars.product_name%> cache transactions and JDBC transactions globally under one umbrella. JTA provides direct coordination between the <%=vars.product_name%> cache and another transactional resource, such as a database. The parties involved in a JTA transaction include:
- The Java application, responsible for starting the global transaction
- The JTA transaction manager, responsible for opening, committing, and rolling back transactions
-- The transaction resource managers, including the Geode cache transaction manager and the JDBC resource manager, responsible for managing operations in the cache and database respectively
+- The transaction resource managers, including the <%=vars.product_name%> cache transaction manager and the JDBC resource manager, responsible for managing operations in the cache and database respectively
-Using JTA, your application controls all transactions in the same standard way, whether the transactions act on the Geode cache, a JDBC resource, or both together. When a JTA global transaction is done, the Geode transaction and the database transaction are both complete.
+Using JTA, your application controls all transactions in the same standard way, whether the transactions act on the <%=vars.product_name%> cache, a JDBC resource, or both together. When a JTA global transaction is done, the <%=vars.product_name%> transaction and the database transaction are both complete.
-When using JTA global transactions with Geode, you have three options:
+When using JTA global transactions with <%=vars.product_name%>, you have three options:
1. Coordinate with an external JTA transaction manager in a container (such as WebLogic or JBoss)
-2. Set Geode as the “last resource” while using a container (such as WebLogic or JBoss) as the JTA transaction manager
-3. Have Geode act as the JTA transaction manager
+2. Set <%=vars.product_name%> as the “last resource” while using a container (such as WebLogic or JBoss) as the JTA transaction manager
+3. Have <%=vars.product_name%> act as the JTA transaction manager
-An application creates a global transaction by using `javax.transaction.UserTransaction` bound to the JNDI context `java:/UserTransaction` to start and terminate transactions. During the transaction, cache operations are done through Geode as usual as described in [Geode Cache Transactions](cache_transactions.html#topic_e15_mr3_5k).
+An application creates a global transaction by using `javax.transaction.UserTransaction` bound to the JNDI context `java:/UserTransaction` to start and terminate transactions. During the transaction, cache operations are done through <%=vars.product_name%> as usual as described in [<%=vars.product_name%> Cache Transactions](cache_transactions.html#topic_e15_mr3_5k).
**Note:**
See the Sun documentation for more information on topics such as JTA, `javax.transaction`, committing and rolling back global transactions, and the related exceptions.
- **[Coordinating with External JTA Transactions Managers](#concept_cp1_zx1_wk)**
- Geode can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
+ <%=vars.product_name%> can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
-- **[Using Geode as the "Last Resource" in a Container-Managed JTA Transaction](#concept_csy_vfb_wk)**
+- **[Using <%=vars.product_name%> as the "Last Resource" in a Container-Managed JTA Transaction](#concept_csy_vfb_wk)**
- The "last resource" feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as Geode) in a transaction with multiple XAResources while ensuring consistency.
+ The "last resource" feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as <%=vars.product_name%>) in a transaction with multiple XAResources while ensuring consistency.
-- **[Using Geode as the JTA Transaction Manager](#concept_8567sdkbigige)**
+- **[Using <%=vars.product_name%> as the JTA Transaction Manager](#concept_8567sdkbigige)**
- You can also use Geode as the JTA transaction manager.
+ You can also use <%=vars.product_name%> as the JTA transaction manager.
-- **[Behavior of Geode Cache Writers and Loaders Under JTA](cache_plugins_with_jta.html)**
+- **[Behavior of <%=vars.product_name%> Cache Writers and Loaders Under JTA](cache_plugins_with_jta.html)**
- When Geode participates in a global transactions, you can still have Geode cache writers and cache loaders operating in the usual way.
+ When <%=vars.product_name%> participates in a global transactions, you can still have <%=vars.product_name%> cache writers and cache loaders operating in the usual way.
- **[Turning Off JTA Transactions](turning_off_jta.html)**
@@ -65,31 +63,31 @@ See the Sun documentation for more information on topics such as JTA, `javax.tra
# Coordinating with External JTA Transactions Managers
-Geode can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
+<%=vars.product_name%> can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
-At startup Geode looks for a TransactionManager (`javax.transaction.TransactionManager`) that has been bound to its JNDI context. When Geode finds such an external transaction manager, all Geode region operations (such as get and put) will participate in global transactions hosted by this external JTA transaction manager.
+At startup <%=vars.product_name%> looks for a TransactionManager (`javax.transaction.TransactionManager`) that has been bound to its JNDI context. When <%=vars.product_name%> finds such an external transaction manager, all <%=vars.product_name%> region operations (such as get and put) will participate in global transactions hosted by this external JTA transaction manager.
-This figure shows the high-level operation of a JTA global transaction whose resources include a Geode cache and a database.
+This figure shows the high-level operation of a JTA global transaction whose resources include a <%=vars.product_name%> cache and a database.
<img src="../../images/transactions_jta_app_server.png" id="concept_cp1_zx1_wk__image_C2935E48415349659FC39BF5C7E75579" class="image" />
An externally coordinated JTA global transaction is run in the following manner:
-1. Each region operation looks up for presence of a global transaction. If one is detected, then a Geode transaction is started automatically, and we register a `javax.transaction.Synchronization` callback with the external JTA transaction manager.
-2. At transaction commit, Geode gets a `beforeCommit()` callback from the external JTA transaction manager. Geode does all locking and conflict detection at this time. If this fails, an exception is thrown back to JTA transaction manager, which then aborts the transaction.
+1. Each region operation looks up for presence of a global transaction. If one is detected, then a <%=vars.product_name%> transaction is started automatically, and we register a `javax.transaction.Synchronization` callback with the external JTA transaction manager.
+2. At transaction commit, <%=vars.product_name%> gets a `beforeCommit()` callback from the external JTA transaction manager. <%=vars.product_name%> does all locking and conflict detection at this time. If this fails, an exception is thrown back to JTA transaction manager, which then aborts the transaction.
3. After a successful `beforeCommit()`callback, JTA transaction manager asks other data sources to commit their transaction.
-4. Geode then gets a `afterCommit()` callback in which changes are applied to the cache and distributed to other members.
+4. <%=vars.product_name%> then gets a `afterCommit()` callback in which changes are applied to the cache and distributed to other members.
You can disable JTA in any region that should not participate in JTA transactions. See [Turning Off JTA Transactions](turning_off_jta.html#concept_nw2_5gs_xk).
## <a id="task_j3g_3mn_1l" class="no-quick-link"></a>How to Run a JTA Transaction Coordinated by an External Transaction Manager
-Use the following procedure to run a Geode global JTA transaction coordinated by an external JTA transaction manager.
+Use the following procedure to run a <%=vars.product_name%> global JTA transaction coordinated by an external JTA transaction manager.
1. **Configure the external data sources in the external container.** Do not configure the data sources in cache.xml . They are not guaranteed to get bound to the JNDI tree.
2.
- Configure Geode for any necessary transactional behavior in the `cache.xml` file. For example, enable `copy-on-read` and specify a transaction listener, as needed. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
+ Configure <%=vars.product_name%> for any necessary transactional behavior in the `cache.xml` file. For example, enable `copy-on-read` and specify a transaction listener, as needed. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
3.
Make sure that JTA transactions are enabled for the regions that will participate in the transaction. See [Turning Off JTA Transactions](turning_off_jta.html#concept_nw2_5gs_xk) for details.
@@ -98,7 +96,7 @@ Use the following procedure to run a Geode global JTA transaction coordinated by
Start the transaction through the external container.
5.
- Initialize the Geode cache. Geode will automatically join the transaction.
+ Initialize the <%=vars.product_name%> cache. <%=vars.product_name%> will automatically join the transaction.
6.
Execute operations in the cache and the database as usual.
@@ -108,22 +106,22 @@ Use the following procedure to run a Geode global JTA transaction coordinated by
<a id="concept_csy_vfb_wk"></a>
-# Using Geode as the "Last Resource" in a Container-Managed JTA Transaction
+# Using <%=vars.product_name%> as the "Last Resource" in a Container-Managed JTA Transaction
-The "last resource" feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as Geode) in a transaction with multiple XAResources while ensuring consistency.
+The "last resource" feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as <%=vars.product_name%>) in a transaction with multiple XAResources while ensuring consistency.
-In the previous two JTA transaction use cases, if the Geode member fails after the other data sources commit but before Geode receives the `afterCommit` callback, Geode and the other data sources may become inconsistent. To prevent this from occurring, you can use the container's "last resource optimization" feature, with Geode set as the "last resource". Using Geode as the last resource ensures that in the event of failure, Geode remains consistent with the other XAResources involved in the transaction.
+In the previous two JTA transaction use cases, if the <%=vars.product_name%> member fails after the other data sources commit but before <%=vars.product_name%> receives the `afterCommit` callback, <%=vars.product_name%> and the other data sources may become inconsistent. To prevent this from occurring, you can use the container's "last resource optimization" feature, with <%=vars.product_name%> set as the "last resource". Using <%=vars.product_name%> as the last resource ensures that in the event of failure, <%=vars.product_name%> remains consistent with the other XAResources involved in the transaction.
-To accomplish this, the application server container must use a JCA Resource Adapter to accomodate Geode as the transaction's last resource. The transaction manager of the container first issues a "prepare" message to the participating XAResources. If the XAResources all accept the transaction, then the manager issues a "commit" instruction to the non-XAResource (in this case, Geode). The non-XAResource (in this case, Geode) participates as a local transaction resource. If the non-XAResource fails, then the transaction manager can rollback the XAResources.
+To accomplish this, the application server container must use a JCA Resource Adapter to accomodate <%=vars.product_name%> as the transaction's last resource. The transaction manager of the container first issues a "prepare" message to the participating XAResources. If the XAResources all accept the transaction, then the manager issues a "commit" instruction to the non-XAResource (in this case, <%=vars.product_name%>). The non-XAResource (in this case, <%=vars.product_name%>) participates as a local transaction resource. If the non-XAResource fails, then the transaction manager can rollback the XAResources.
<img src="../../images/transactions_jca_adapter.png" id="concept_csy_vfb_wk__image_opb_sgb_wk" class="image" />
<a id="task_sln_x3b_wk"></a>
-# How to Run JTA Transactions with Geode as a "Last Resource"
+# How to Run JTA Transactions with <%=vars.product_name%> as a "Last Resource"
1. Locate the version-specific `geode-jca` RAR file within
-the `lib` directory of your Geode installation.
+the `lib` directory of your <%=vars.product_name%> installation.
2. Add your container-specific XML file to the `geode-jca` RAR file.
<ol>
<li>Create a container-specific resource adapter XML file named <container>-ra.xml. For example, an XML file for a WebLogic resource adapter XML file might look something like this:
@@ -158,7 +156,7 @@ the CLASSPATH of the JTA transaction coordinator container.
4. Deploy the version-specific `geode-jca` RAR file on
the JTA transaction coordinator container.
When deploying the file, you specify the JNDI name and so on.
-5. Configure Geode for any necessary transactional behavior. Enable `copy-on-read` and specify a transaction listener, if you need one. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
+5. Configure <%=vars.product_name%> for any necessary transactional behavior. Enable `copy-on-read` and specify a transaction listener, if you need one. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
6. Get an initial context through `org.apache.geode.cache.GemFireCache.getJNDIContext`. For example:
``` pre
@@ -167,13 +165,13 @@ When deploying the file, you specify the JNDI name and so on.
This returns `javax.naming.Context` and gives you the JNDI associated with the cache. The context contains the `TransactionManager`, `UserTransaction`, and any configured JDBC resource manager.
-7. Start and commit the global transaction using the `UserTransaction` object rather than with Geode's `CacheTransactionManager`.
+7. Start and commit the global transaction using the `UserTransaction` object rather than with <%=vars.product_name%>'s `CacheTransactionManager`.
``` pre
UserTransaction txManager = (UserTransaction)ctx.lookup("java:/UserTransaction");
```
-8. Obtain a Geode connection.
+8. Obtain a <%=vars.product_name%> connection.
``` pre
GFConnectionFactory cf = (GFConnectionFactory) ctx.lookup("gfe/jca");
@@ -187,40 +185,40 @@ When deploying the file, you specify the JNDI name and so on.
See [JCA Resource Adapter Example](jca_adapter_example.html#concept_swv_z2p_wk) for an example of how to set up a transaction using the JCA Resource Adapter.
-## <a id="concept_8567sdkbigige" class="no-quick-link"></a>Using Geode as the JTA Transaction Manager
+## <a id="concept_8567sdkbigige" class="no-quick-link"></a>Using <%=vars.product_name%> as the JTA Transaction Manager
-You can also use Geode as the JTA transaction manager.
-As of Geode 1.2, Geode's JTA transaction manager is deprecated.
+You can also use <%=vars.product_name%> as the JTA transaction manager.
+As of <%=vars.product_name%> 1.2, <%=vars.product_name%>'s JTA transaction manager is deprecated.
-Geode ships with its own implementation of a JTA transaction manager. However, note that this implementation is not XA-compliant; therefore, it does not persist any state, which could lead to an inconsistent state after recovering a crashed member.
+<%=vars.product_name%> ships with its own implementation of a JTA transaction manager. However, note that this implementation is not XA-compliant; therefore, it does not persist any state, which could lead to an inconsistent state after recovering a crashed member.
<img src="../../images/transactions_jta.png" id="concept_8567sdkbigige__image_C8D94070E55F4BCC8B5FF3D5BEBA99ED" class="image" />
-The Geode JTA transaction manager is initialized when the Geode cache is initialized. Until then, JTA is not available for use. The application starts a JTA transaction by using the `UserTransaction.begin` method. The `UserTransaction` object is the application’s handle to instruct the JTA transaction manager on what to do.
+The <%=vars.product_name%> JTA transaction manager is initialized when the <%=vars.product_name%> cache is initialized. Until then, JTA is not available for use. The application starts a JTA transaction by using the `UserTransaction.begin` method. The `UserTransaction` object is the application’s handle to instruct the JTA transaction manager on what to do.
-The Geode JTA implementation also supports the J2EE Connector Architecture (JCA) `ManagedConnectionFactory`.
+The <%=vars.product_name%> JTA implementation also supports the J2EE Connector Architecture (JCA) `ManagedConnectionFactory`.
-The Geode implementation of JTA has the following limitations:
+The <%=vars.product_name%> implementation of JTA has the following limitations:
- Only one JDBC database instance per transaction is allowed, although you can have multiple connections to that database.
- Multiple threads cannot participate in a transaction.
- Transaction recovery after a crash is not supported.
-In addition, JTA transactions are subject to the limitations of Geode cache transactions such as not being supported on regions with global scope. When a global transaction needs to access the Geode cache, JTA silently starts a Geode cache transaction.
+In addition, JTA transactions are subject to the limitations of <%=vars.product_name%> cache transactions such as not being supported on regions with global scope. When a global transaction needs to access the <%=vars.product_name%> cache, JTA silently starts a <%=vars.product_name%> cache transaction.
<a id="task_qjv_khb_wk"></a>
-# How to Run a JTA Global Transaction Using Geode as the JTA Transaction Manager
+# How to Run a JTA Global Transaction Using <%=vars.product_name%> as the JTA Transaction Manager
-This topic describes how to run a JTA global transaction in Geode .
+This topic describes how to run a JTA global transaction in <%=vars.product_name%> .
To run a global transaction, perform the following steps:
1. Configure the external data sources in the `cache.xml` file. See [Configuring Database Connections Using JNDI](configuring_db_connections_using_JNDI.html#topic_A5E3A67C808D48C08E1F0DC167C5C494) for examples.
2. Include the JAR file for any data sources in your CLASSPATH.
-3. Configure Geode for any necessary transactional behavior. Enable `copy-on-read` for your cache and specify a transaction listener, if you need one. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
+3. Configure <%=vars.product_name%> for any necessary transactional behavior. Enable `copy-on-read` for your cache and specify a transaction listener, if you need one. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k) and [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for details.
4. Make sure that JTA transactions are not disabled in the `cache.xml` file or the application code.
-5. Initialize the Geode cache.
+5. Initialize the <%=vars.product_name%> cache.
6. Get an initial context through `org.apache.geode.cache.GemFireCache.getJNDIContext`. For example:
``` pre
@@ -236,11 +234,11 @@ To run a global transaction, perform the following steps:
```
With `UserTransaction`, you can begin, commit, and rollback transactions.
- If a global transaction exists when you use the cache, it automatically joins the transaction. Operations on a region automatically detect and become associated with the existing global transaction through JTA synchronization. If the global transaction has been marked for rollback, however, the Geode cache is not allowed to enlist with that transaction. Any cache operation that causes an attempt to enlist throws a `FailedSynchronizationException`.
+ If a global transaction exists when you use the cache, it automatically joins the transaction. Operations on a region automatically detect and become associated with the existing global transaction through JTA synchronization. If the global transaction has been marked for rollback, however, the <%=vars.product_name%> cache is not allowed to enlist with that transaction. Any cache operation that causes an attempt to enlist throws a `FailedSynchronizationException`.
- The Geode cache transaction’s commit or rollback is triggered when the global transaction commits or rolls back. When the global transaction is committed using the `UserTransaction` interface, the transactions of any registered JTA resources are committed, including the Geode cache transaction. If the cache or database transaction fails to commit, the `UserTransaction` call throws a `TransactionRolledBackException`. If a commit or rollback is attempted directly on a Geode transaction that is registered with JTA, that action throws an `IllegalStateException`.
+ The <%=vars.product_name%> cache transaction’s commit or rollback is triggered when the global transaction commits or rolls back. When the global transaction is committed using the `UserTransaction` interface, the transactions of any registered JTA resources are committed, including the <%=vars.product_name%> cache transaction. If the cache or database transaction fails to commit, the `UserTransaction` call throws a `TransactionRolledBackException`. If a commit or rollback is attempted directly on a <%=vars.product_name%> transaction that is registered with JTA, that action throws an `IllegalStateException`.
-See [Geode JTA Transaction Example](transaction_jta_gemfire_example.html#concept_ffg_sj5_1l).
+See [<%=vars.product_name%> JTA Transaction Example](transaction_jta_gemfire_example.html#concept_ffg_sj5_1l).
- **[Configuring Database Connections Using JNDI](configuring_db_connections_using_JNDI.html)**
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/about_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/about_transactions.html.md.erb b/geode-docs/developing/transactions/about_transactions.html.md.erb
index c0e3261..bc9e371 100644
--- a/geode-docs/developing/transactions/about_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/about_transactions.html.md.erb
@@ -22,26 +22,26 @@ limitations under the License.
<a id="topic_jbt_2y4_wk"></a>
-This section covers the features of Geode transactions.
+This section covers the features of <%=vars.product_name%> transactions.
-Geode transactions provide the following features:
+<%=vars.product_name%> transactions provide the following features:
- Basic transaction properties: atomicity, consistency, isolation, and durability
-- Rollback and commit operations along with standard Geode cache operations
+- Rollback and commit operations along with standard <%=vars.product_name%> cache operations
- Ability to suspend and resume transactions
- High concurrency and high performance
- Transaction statistics gathering and archiving
-- Compatibility with Java Transaction API (JTA) transactions, using either Geode JTA or a third-party implementation
-- Ability to use Geode as a “last resource” in JTA transactions with multiple data sources to guarantee transactional consistency
+- Compatibility with Java Transaction API (JTA) transactions, using either <%=vars.product_name%> JTA or a third-party implementation
+- Ability to use <%=vars.product_name%> as a “last resource” in JTA transactions with multiple data sources to guarantee transactional consistency
## Types of Transactions
-Geode supports two kinds of transactions: **Geode cache transactions** and **JTA global transactions**.
+<%=vars.product_name%> supports two kinds of transactions: **<%=vars.product_name%> cache transactions** and **JTA global transactions**.
-Geode cache transactions are used to group the execution of cache operations and to gain the control offered by transactional commit and rollback. Applications create cache transactions by using an instance of the Geode `CacheTransactionManager`. During a transaction, cache operations are performed and distributed through Geode as usual. See [Geode Cache Transactions](cache_transactions.html#topic_e15_mr3_5k) for details on Geode cache transactions and how these transactions work.
+<%=vars.product_name%> cache transactions are used to group the execution of cache operations and to gain the control offered by transactional commit and rollback. Applications create cache transactions by using an instance of the <%=vars.product_name%> `CacheTransactionManager`. During a transaction, cache operations are performed and distributed through <%=vars.product_name%> as usual. See [<%=vars.product_name%> Cache Transactions](cache_transactions.html#topic_e15_mr3_5k) for details on <%=vars.product_name%> cache transactions and how these transactions work.
-JTA global transactions allow you to use the standard JTA interface to coordinate Geode transactions with JDBC transactions. When performing JTA global transactions, you have the option of using Geode’s own implementation of JTA or a third party’s implementation (typically application servers such as WebLogic or JBoss) of JTA. In addition, some third party JTA implementations allow you to set Geode as a “last resource” to ensure transactional consistency across data sources in the event that Geode or another data source becomes unavailable. For global transactions, applications use `java:/UserTransaction` to start and terminate transactions while Geode cache operations are performed in the same manner as regular Geode cache transactions. See [JTA Global Transactions with Geode](JTA_transactions.html) for details on JTA Global transactions.
+JTA global transactions allow you to use the standard JTA interface to coordinate <%=vars.product_name%> transactions with JDBC transactions. When performing JTA global transactions, you have the option of using <%=vars.product_name%>’s own implementation of JTA or a third party’s implementation (typically application servers such as WebLogic or JBoss) of JTA. In addition, some third party JTA implementations allow you to set <%=vars.product_name%> as a “last resource” to ensure transactional consistency across data sources in the event that <%=vars.product_name%> or another data source becomes unavailable. For global transactions, applications use `java:/UserTransaction` to start and terminate transactions while <%=vars.product_name%> cache operations are performed in the same manner as regular <%=vars.product_name%> cache transactions. See [JTA Global Transactions with <%=vars.product_name%>](JTA_transactions.html) for details on JTA Global transactions.
-You can also coordinate a Geode 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 Geode Cache Transaction that Coordinates with an External Database](run_a_cache_transaction_with_external_db.html#task_sdn_2qk_2l).
+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).
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/cache_plugins_with_jta.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/cache_plugins_with_jta.html.md.erb b/geode-docs/developing/transactions/cache_plugins_with_jta.html.md.erb
index 7735bf0..7df64bc 100644
--- a/geode-docs/developing/transactions/cache_plugins_with_jta.html.md.erb
+++ b/geode-docs/developing/transactions/cache_plugins_with_jta.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Behavior of Geode Cache Writers and Loaders Under JTA
----
+<% set_title("Behavior of", product_name, "Cache Writers and Loaders Under JTA") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -19,10 +17,10 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-When Geode participates in a global transactions, you can still have Geode cache writers and cache loaders operating in the usual way.
+When <%=vars.product_name%> participates in a global transactions, you can still have <%=vars.product_name%> cache writers and cache loaders operating in the usual way.
For example, in addition to the transactional connection to the database, the region could also have a cache writer and cache loader configured to exchange data with that same database. As long as the data source is transactional, which means that it can detect the transaction manager, the cache writer and cache loader participate in the transaction. If the JTA rolls back its transaction, the changes made by the cache loader and the cache writer are rolled back. For more on transactional data sources, see the discussion of XAPooledDataSource and ManagedDataSource in[Configuring Database Connections Using JNDI](configuring_db_connections_using_JNDI.html#topic_A5E3A67C808D48C08E1F0DC167C5C494).
-If you are using a Geode cache or transaction listener with global transactions, be aware that the EntryEvent returned by a transaction has the Geode transaction ID, not the JTA transaction ID.
+If you are using a <%=vars.product_name%> cache or transaction listener with global transactions, be aware that the EntryEvent returned by a transaction has the <%=vars.product_name%> transaction ID, not the JTA transaction ID.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/cache_transaction_performance.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/cache_transaction_performance.html.md.erb b/geode-docs/developing/transactions/cache_transaction_performance.html.md.erb
index 5f25453..97134bc 100644
--- a/geode-docs/developing/transactions/cache_transaction_performance.html.md.erb
+++ b/geode-docs/developing/transactions/cache_transaction_performance.html.md.erb
@@ -23,7 +23,7 @@ Cache transaction performance can vary depending on the type of regions you are
The most common region configurations for use with transactions are distributed replicated and partitioned:
-- Replicated regions are better suited for running transactions on small to mid-size data sets. To ensure all or nothing behavior, at commit time, distributed transactions use the global reservation system of the Geode distributed lock service. This works well as long as the data set is reasonably small.
+- Replicated regions are better suited for running transactions on small to mid-size data sets. To ensure all or nothing behavior, at commit time, distributed transactions use the global reservation system of the <%=vars.product_name%> distributed lock service. This works well as long as the data set is reasonably small.
- Partitioned regions are the right choice for highly-performant, scalable operations. Transactions on partitioned regions use only local locking, and only send messages to the redundant data stores at commit time. Because of this, these transactions perform much better than distributed transactions. There are no global locks, so partitioned transactions are extremely scalable as well.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/cache_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/cache_transactions.html.md.erb b/geode-docs/developing/transactions/cache_transactions.html.md.erb
index 7e00e42..8b5d0f6 100644
--- a/geode-docs/developing/transactions/cache_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/cache_transactions.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Geode Cache Transactions
----
+<% set_title(product_name, "Cache Transactions") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -22,30 +20,30 @@ limitations under the License.
<a id="topic_e15_mr3_5k"></a>
-Use Geode cache transactions to group the execution of cache operations and to gain the control offered by transactional commit and rollback. Geode cache transactions control operations within the Geode cache while the Geode distributed system handles data distribution in the usual way.
+Use <%=vars.product_name%> cache transactions to group the execution of cache operations and to gain the control offered by transactional commit and rollback. <%=vars.product_name%> cache transactions control operations within the <%=vars.product_name%> cache while the <%=vars.product_name%> distributed system handles data distribution in the usual way.
-- **[Cache Transaction Performance](../../developing/transactions/cache_transaction_performance.html)**
+- **[Cache Transaction Performance](cache_transaction_performance.html)**
Cache transaction performance can vary depending on the type of regions you are using.
-- **[Data Location for Cache Transactions](../../developing/transactions/data_location_cache_transactions.html)**
+- **[Data Location for Cache Transactions](data_location_cache_transactions.html)**
The location where you can run your transaction depends on where you are storing your data.
-- **[How to Run a Geode Cache Transaction](../../developing/transactions/run_a_cache_transaction.html)**
+- **[How to Run a <%=vars.product_name%> Cache Transaction](run_a_cache_transaction.html)**
- This topic describes how to run a Geode cache transaction.
+ This topic describes how to run a <%=vars.product_name%> cache transaction.
-- **[How to Run a Geode Cache Transaction that Coordinates with an External Database](../../developing/transactions/run_a_cache_transaction_with_external_db.html)**
+- **[How to Run a <%=vars.product_name%> Cache Transaction that Coordinates with an External Database](run_a_cache_transaction_with_external_db.html)**
- Coordinate a Geode cache transaction with an external database by using CacheWriter/CacheListener and TransactionWriter/TransactionListener plug-ins, **to provide an alternative to using JTA transactions**.
+ Coordinate a <%=vars.product_name%> cache transaction with an external database by using CacheWriter/CacheListener and TransactionWriter/TransactionListener plug-ins, **to provide an alternative to using JTA transactions**.
-- **[Working with Geode Cache Transactions](../../developing/transactions/working_with_transactions.html)**
+- **[Working with <%=vars.product_name%> Cache Transactions](working_with_transactions.html)**
- 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.
-- **[How Geode Cache Transactions Work](../../developing/transactions/how_cache_transactions_work.html#topic_fls_1j1_wk)**
+- **[How <%=vars.product_name%> Cache Transactions Work](how_cache_transactions_work.html#topic_fls_1j1_wk)**
- This section provides an explanation of how transactions work on Geode caches.
+ This section provides an explanation of how transactions work on <%=vars.product_name%> caches.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb b/geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
index 550d755..7811bcb 100644
--- a/geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
+++ b/geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
@@ -21,7 +21,7 @@ limitations under the License.
<a id="topic_nlq_sk1_wk"></a>
-A transaction is managed on a per-cache basis, so multiple regions in the cache can participate in a single transaction. The data scope of a Geode cache transaction is the cache that hosts the transactional data. For partitioned regions, this may be a remote host to the one running the transaction application. Any transaction that includes one or more partitioned regions is run on the member storing the primary copy of the partitioned region data. Otherwise, the transaction host is the same one running the application.
+A transaction is managed on a per-cache basis, so multiple regions in the cache can participate in a single transaction. The data scope of a <%=vars.product_name%> cache transaction is the cache that hosts the transactional data. For partitioned regions, this may be a remote host to the one running the transaction application. Any transaction that includes one or more partitioned regions is run on the member storing the primary copy of the partitioned region data. Otherwise, the transaction host is the same one running the application.
- The client executing the transaction code is called the transaction initiator.
@@ -83,7 +83,7 @@ The region’s scope affects how data is distributed during the commit phase. Tr
Transactions on non-replicated regions (regions that use the old API with DataPolicy EMPTY, NORMAL and PRELOADED) are always transaction initiators, and the transaction data host is always a member with a replicated region. This is similar to the way transactions using the PARTITION\_PROXY shortcut are forwarded to members with primary bucket.
**Note:**
-When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that the Geode property `conserve-sockets` is set to false to avoid distributed deadlocks. An empty region is a region created with the API `RegionShortcut.REPLICATE_PROXY` or a region with that uses the old API of `DataPolicy` set to `EMPTY`.
+When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that the <%=vars.product_name%> property `conserve-sockets` is set to false to avoid distributed deadlocks. An empty region is a region created with the API `RegionShortcut.REPLICATE_PROXY` or a region with that uses the old API of `DataPolicy` set to `EMPTY`.
## Conflicting Transactions in Distributed-Ack Regions
@@ -97,7 +97,7 @@ In this series of figures, even after the commit operation is launched, the tran
<img src="../../images_svg/transactions_replicate_2.svg" id="concept_nl5_pk1_wk__image_sbh_21k_54" class="image" />
-**Step 3:** Changes are in transit. T1 commits and its changes are merged into the local cache. The commit does not complete until Geode distributes the changes to the remote regions and acknowledgment is received.
+**Step 3:** Changes are in transit. T1 commits and its changes are merged into the local cache. The commit does not complete until <%=vars.product_name%> distributes the changes to the remote regions and acknowledgment is received.
<img src="../../images_svg/transactions_replicate_3.svg" id="concept_nl5_pk1_wk__image_qgl_k1k_54" class="image" />
@@ -113,7 +113,7 @@ These figures show how using the no-ack scope can produce unexpected results. Th
<img src="../../images_svg/transactions_replicate_1.svg" id="concept_nl5_pk1_wk__image_jn2_cbk_54" class="image" />
-**Step 2:** Changes are in transit. Transactions T1 and T2 commit and merge their changes into the local cache. Geode then distributes changes to the remote regions.
+**Step 2:** Changes are in transit. Transactions T1 and T2 commit and merge their changes into the local cache. <%=vars.product_name%> then distributes changes to the remote regions.
<img src="../../images_svg/transactions_replicate_no_ack_1.svg" id="concept_nl5_pk1_wk__image_fk1_hbk_54" class="image" />
@@ -129,18 +129,18 @@ When encountering conflicts with local scope, the first transaction to start the
## Transactions and Persistent Regions
<a id="concept_omy_341_wk"></a>
-By default, Geode does not allow transactions on persistent regions. You can enable the use of transactions on persistent regions by setting the property `gemfire.ALLOW_PERSISTENT_TRANSACTIONS` to true. This may also be accomplished at server startup using gfsh:
+By default, <%=vars.product_name%> does not allow transactions on persistent regions. You can enable the use of transactions on persistent regions by setting the property `gemfire.ALLOW_PERSISTENT_TRANSACTIONS` to true. This may also be accomplished at server startup using gfsh:
``` pre
gfsh start server --name=server1 --dir=server1_dir \
--J=-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true
```
-Since Geode does not provide atomic disk persistence guarantees, the default behavior is to disallow disk-persistent regions from participating in transactions. However, when choosing to enable transactions on persistent regions, consider the following:
+Since <%=vars.product_name%> does not provide atomic disk persistence guarantees, the default behavior is to disallow disk-persistent regions from participating in transactions. However, when choosing to enable transactions on persistent regions, consider the following:
-- Geode does ensure atomicity for in-memory updates.
+- <%=vars.product_name%> does ensure atomicity for in-memory updates.
- When any failed member is unable to complete the logic triggered by a transaction (including subsequent disk writes), that failed member is removed from the distributed system and, if restarted, must rebuild its state from surviving nodes that successfully complete the updates.
-- The chances of multiple nodes failing to complete the disk writes that result from a transaction commit due to nodes crashing for unrelated reasons are small. The real risk is that the file system buffers holding the persistent updates do not get written to disk in the case of operating system or hardware failure. If only the Geode process crashes, atomicity still exists. The overall risk of losing disk updates can also be mitigated by enabling synchronized disk file mode for the disk stores, but this incurs a high performance penalty.
+- The chances of multiple nodes failing to complete the disk writes that result from a transaction commit due to nodes crashing for unrelated reasons are small. The real risk is that the file system buffers holding the persistent updates do not get written to disk in the case of operating system or hardware failure. If only the <%=vars.product_name%> process crashes, atomicity still exists. The overall risk of losing disk updates can also be mitigated by enabling synchronized disk file mode for the disk stores, but this incurs a high performance penalty.
To mitigate the risk of data not get fully written to disk on all copies of the participating persistent disk stores:
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/chapter_overview.html.md.erb b/geode-docs/developing/transactions/chapter_overview.html.md.erb
index defcf4b..0f2dc37 100644
--- a/geode-docs/developing/transactions/chapter_overview.html.md.erb
+++ b/geode-docs/developing/transactions/chapter_overview.html.md.erb
@@ -19,27 +19,27 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Geode provides a transactions API, with `begin`, `commit`, and `rollback` methods. These methods are much the same as the familiar relational database transactions methods.
+<%=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](../../developing/transactions/about_transactions.html)**
+- **[About Transactions](about_transactions.html)**
- This section covers the features of Geode transactions.
-It also details the two kinds of transaction that Geode supports:
-**Geode cache transactions** and **JTA global transactions**.
+ This section covers the features of <%=vars.product_name%> transactions.
+It also details the two kinds of transaction that <%=vars.product_name%> supports:
+**<%=vars.product_name%> cache transactions** and **JTA global transactions**.
-- **[Geode Cache Transactions](../../developing/transactions/cache_transactions.html)**
+- **[<%=vars.product_name%> Cache Transactions](cache_transactions.html)**
- Use Geode cache transactions to group the execution of cache operations and to gain the control offered by transactional commit and rollback. Geode cache transactions control operations within the Geode cache while the Geode distributed system handles data distribution in the usual way.
+ Use <%=vars.product_name%> cache transactions to group the execution of cache operations and to gain the control offered by transactional commit and rollback. <%=vars.product_name%> cache transactions control operations within the <%=vars.product_name%> cache while the <%=vars.product_name%> distributed system handles data distribution in the usual way.
-- **[JTA Global Transactions with Geode](../../developing/transactions/JTA_transactions.html)**
+- **[JTA Global Transactions with <%=vars.product_name%>](JTA_transactions.html)**
- Use JTA global transactions to coordinate Geode cache transactions and JDBC transactions.
+ Use JTA global transactions to coordinate <%=vars.product_name%> cache transactions and JDBC transactions.
-- **[Monitoring and Troubleshooting Transactions](../../developing/transactions/monitor_troubleshoot_transactions.html)**
+- **[Monitoring and Troubleshooting Transactions](monitor_troubleshoot_transactions.html)**
- This topic covers errors that may occur when running transactions in Geode.
+ This topic covers errors that may occur when running transactions in <%=vars.product_name%>.
-- **[Transaction Coding Examples](../../developing/transactions/transaction_coding_examples.html)**
+- **[Transaction Coding Examples](transaction_coding_examples.html)**
This section provides several code examples for writing and executing transactions.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/client_server_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/client_server_transactions.html.md.erb b/geode-docs/developing/transactions/client_server_transactions.html.md.erb
index 727683a..4781bd7f 100644
--- a/geode-docs/developing/transactions/client_server_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/client_server_transactions.html.md.erb
@@ -20,19 +20,19 @@ limitations under the License.
-->
-The syntax for writing client transactions is the same on the Java client as with any other Geode member, but the underlying behavior in a client-run transaction is different from general transaction behavior.
+The syntax for writing client transactions is the same on the Java client as with any other <%=vars.product_name%> member, but the underlying behavior in a client-run transaction is different from general transaction behavior.
-For general information about running a transaction, refer to [How to Run a Geode Cache Transaction](run_a_cache_transaction.html#task_f15_mr3_5k).
+For general information about running a transaction, refer to [How to Run a <%=vars.product_name%> Cache Transaction](run_a_cache_transaction.html#task_f15_mr3_5k).
-- **[How Geode Runs Client Transactions](../../developing/transactions/client_server_transactions.html#how_gemfire_runs_clients)**
+- **[How <%=vars.product_name%> Runs Client Transactions](client_server_transactions.html#how_gemfire_runs_clients)**
-- **[Client Cache Access During a Transaction](../../developing/transactions/client_server_transactions.html#client_cache_access)**
+- **[Client Cache Access During a Transaction](client_server_transactions.html#client_cache_access)**
-- **[Client Transactions and Client Application Plug-Ins](../../developing/transactions/client_server_transactions.html#client_app_plugins)**
+- **[Client Transactions and Client Application Plug-Ins](client_server_transactions.html#client_app_plugins)**
-- **[Client Transaction Failures](../../developing/transactions/client_server_transactions.html#client_transaction_failures)**
+- **[Client Transaction Failures](client_server_transactions.html#client_transaction_failures)**
-## <a id="how_gemfire_runs_clients" class="no-quick-link"></a>How Geode Runs Client Transactions
+## <a id="how_gemfire_runs_clients" class="no-quick-link"></a>How <%=vars.product_name%> Runs Client Transactions
When a client performs a transaction, the transaction is delegated to a server that acts as the transaction initiator in the server system. As with regular, non-client transactions, this server delegate may or may not be the transaction host.
@@ -42,7 +42,7 @@ In this figure, the application code on the client makes changes to data entries
## <a id="client_cache_access" class="no-quick-link"></a>Client Cache Access During a Transaction
-To maintain cache consistency, Geode blocks access to the local client cache during a transaction. The local client cache may reflect information inconsistent with the transaction in progress. When the transaction completes, the local cache is accessible again.
+To maintain cache consistency, <%=vars.product_name%> blocks access to the local client cache during a transaction. The local client cache may reflect information inconsistent with the transaction in progress. When the transaction completes, the local cache is accessible again.
## <a id="client_app_plugins" class="no-quick-link"></a>Client Transactions and Client Application Plug-Ins
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/configuring_db_connections_using_JNDI.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/configuring_db_connections_using_JNDI.html.md.erb b/geode-docs/developing/transactions/configuring_db_connections_using_JNDI.html.md.erb
index 4a08b6a..f58d04e 100644
--- a/geode-docs/developing/transactions/configuring_db_connections_using_JNDI.html.md.erb
+++ b/geode-docs/developing/transactions/configuring_db_connections_using_JNDI.html.md.erb
@@ -31,9 +31,9 @@ The following are a list of `DataSource` connection types used in JTA transactio
- **PooledDataSource**. Pooled SQL connections.
- **SimpleDataSource**. Single SQL connection. No pooling of SQL connections is done. Connections are generated on the fly and cannot be reused.
-The `jndi-name` attribute of the `jndi-binding` element is the key binding parameter. If the value of `jndi-name` is a DataSource, it is bound as `java:/`*myDatabase*, where *myDatabase* is the name you assign to your data source. If the data source cannot be bound to JNDI at runtime, Geode logs a warning. For information on the `DataSource` interface, see: [http://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html](http://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)
+The `jndi-name` attribute of the `jndi-binding` element is the key binding parameter. If the value of `jndi-name` is a DataSource, it is bound as `java:/`*myDatabase*, where *myDatabase* is the name you assign to your data source. If the data source cannot be bound to JNDI at runtime, <%=vars.product_name%> logs a warning. For information on the `DataSource` interface, see: [http://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html](http://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)
-Geode supports JDBC 2.0 and 3.0.
+<%=vars.product_name%> supports JDBC 2.0 and 3.0.
**Note:**
Include any data source JAR files in your CLASSPATH.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/how_cache_transactions_work.html.md.erb
----------------------------------------------------------------------
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 4cb0473..c7bca5b 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
@@ -1,6 +1,4 @@
----
-title: How Geode Cache Transactions Work
----
+<% set_title("How", product_name, "Cache Transactions Work") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -21,21 +19,21 @@ limitations under the License.
<a id="topic_fls_1j1_wk"></a>
-This section provides an explanation of how transactions work on Geode caches.
+This section provides an explanation of how transactions work on <%=vars.product_name%> caches.
-All the regions in a Geode member cache can participate in a transaction. A Java application can operate on the cache using multiple transactions. A transaction is associated with only one thread, and a thread can operate on only one transaction at a time. Child threads do not inherit existing transactions.
+All the regions in a <%=vars.product_name%> member cache can participate in a transaction. A Java application can operate on the cache using multiple transactions. A transaction is associated with only one thread, and a thread can operate on only one transaction at a time. Child threads do not inherit existing transactions.
-- **[Transaction View](../../developing/transactions/how_cache_transactions_work.html#concept_hls_1j1_wk)**
+- **[Transaction View](#concept_hls_1j1_wk)**
-- **[Committing Transactions](../../developing/transactions/how_cache_transactions_work.html#concept_sbj_lj1_wk)**
+- **[Committing Transactions](#concept_sbj_lj1_wk)**
-- **[Transactions by Region Type](../../developing/transactions/cache_transactions_by_region_type.html#topic_nlq_sk1_wk)**
+- **[Transactions by Region Type](cache_transactions_by_region_type.html#topic_nlq_sk1_wk)**
-- **[Client Transactions](../../developing/transactions/client_server_transactions.html)**
+- **[Client Transactions](client_server_transactions.html)**
-- **[Comparing Transactional and Non-Transactional Operations](../../developing/transactions/transactional_and_nontransactional_ops.html#transactional_and_nontransactional_ops)**
+- **[Comparing Transactional and Non-Transactional Operations](transactional_and_nontransactional_ops.html#transactional_and_nontransactional_ops)**
-- **[Geode Cache Transaction Semantics](../../developing/transactions/transaction_semantics.html)**
+- **[<%=vars.product_name%> Cache Transaction Semantics](transaction_semantics.html)**
## Transaction View
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/jca_adapter_example.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/jca_adapter_example.html.md.erb b/geode-docs/developing/transactions/jca_adapter_example.html.md.erb
index 409b93e..1c7b420 100644
--- a/geode-docs/developing/transactions/jca_adapter_example.html.md.erb
+++ b/geode-docs/developing/transactions/jca_adapter_example.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-This example shows how to use the JCA Resource Adapter in Geode .
+This example shows how to use the JCA Resource Adapter in <%=vars.product_name%> .
``` pre
Hashtable env = new Hashtable();
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/monitor_troubleshoot_transactions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/monitor_troubleshoot_transactions.html.md.erb b/geode-docs/developing/transactions/monitor_troubleshoot_transactions.html.md.erb
index 7956cac..b2ba4df 100644
--- a/geode-docs/developing/transactions/monitor_troubleshoot_transactions.html.md.erb
+++ b/geode-docs/developing/transactions/monitor_troubleshoot_transactions.html.md.erb
@@ -19,14 +19,14 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-This topic covers errors that may occur when running transactions in Geode.
+This topic covers errors that may occur when running transactions in <%=vars.product_name%>.
<a id="monitor_troubleshoot_transactions__section_881D2FF6761B4D689DDB46C650E2A2E1"></a>
-Unlike database transactions, Geode does not write a transaction log to disk. To get the full details about committed operations, use a transaction listener to monitor the transaction events and their contained cache events for each of your transactions.
+Unlike database transactions, <%=vars.product_name%> does not write a transaction log to disk. To get the full details about committed operations, use a transaction listener to monitor the transaction events and their contained cache events for each of your transactions.
## <a id="monitor_troubleshoot_transactions__section_2B66338C851A4FF386B60CC5CF4DCF77" class="no-quick-link"></a>Statistics on Cache Transactions
-During the operation of Geode cache transactions, if statistics are enabled, transaction-related statistics are calculated and accessible from the CachePerfStats statistic resource. Because the transaction’s data scope is the cache, these statistics are collected on a per-cache basis.
+During the operation of <%=vars.product_name%> cache transactions, if statistics are enabled, transaction-related statistics are calculated and accessible from the CachePerfStats statistic resource. Because the transaction’s data scope is the cache, these statistics are collected on a per-cache basis.
## <a id="monitor_troubleshoot_transactions__section_EA9277E6CFD7423F95BA4D04955FDE2A" class="no-quick-link"></a>Commit
@@ -38,7 +38,7 @@ A transaction can create data beyond the capacity limit set in the region’s ev
## <a id="monitor_troubleshoot_transactions__section_C7588E4F143B4D7FAFAEDCF5AE4FF2C8" class="no-quick-link"></a>Interaction with the Resource Manager
-The Geode resource manager, which controls overall heap use, either allows all transactional operations or blocks the entire transaction. If a cache reaches the critical threshold in the middle of a commit, the commit is allowed to finish before the manager starts blocking operations.
+The <%=vars.product_name%> resource manager, which controls overall heap use, either allows all transactional operations or blocks the entire transaction. If a cache reaches the critical threshold in the middle of a commit, the commit is allowed to finish before the manager starts blocking operations.
## <a id="monitor_troubleshoot_transactions__section_8942ABA6F23C4ED58877C894B13F4F21" class="no-quick-link"></a>Transaction Exceptions
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/run_a_cache_transaction.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/run_a_cache_transaction.html.md.erb b/geode-docs/developing/transactions/run_a_cache_transaction.html.md.erb
index 7ec2be6..90b1183 100644
--- a/geode-docs/developing/transactions/run_a_cache_transaction.html.md.erb
+++ b/geode-docs/developing/transactions/run_a_cache_transaction.html.md.erb
@@ -1,6 +1,4 @@
----
-title: How to Run a Geode Cache Transaction
----
+<% set_title("How to Run a", product_name, "Cache Transaction") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -21,9 +19,9 @@ limitations under the License.
<a id="task_f15_mr3_5k"></a>
-This topic describes how to run a Geode cache transaction.
+This topic describes how to run a <%=vars.product_name%> cache transaction.
-Applications manage transactions on a per-cache basis. A Geode cache transaction starts with a `CacheTransactionManager.begin` method and continues with a series of operations, which are typically region operations such as region create, update, clear and destroy. The begin, commit, and rollback are directly controlled by the application. A commit, failed commit, or voluntary rollback by the transaction manager ends the transaction.
+Applications manage transactions on a per-cache basis. A <%=vars.product_name%> cache transaction starts with a `CacheTransactionManager.begin` method and continues with a series of operations, which are typically region operations such as region create, update, clear and destroy. The begin, commit, and rollback are directly controlled by the application. A commit, failed commit, or voluntary rollback by the transaction manager ends the transaction.
You can run transactions on any type of cache region except regions with **global** scope. An operation attempted on a region with global scope throws an `UnsupportedOperationException` exception.
@@ -38,10 +36,10 @@ This discussion centers on transactions on replicated and partitioned regions. I
|---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **replicated regions** | Use `distributed-ack` scope. The region shortcuts specifying `REPLICATE` use `distributed-ack` scope. This is particularly important if you have more than one data producer. With one data producer, you can safely use `distributed-no-ack`. |
| **partitioned regions** | Custom partition and colocate data among regions so all the data for any single transaction is hosted by a single member. If the transaction is run from a member other than the one hosting the data, the transaction will run by proxy in the member hosting the data. The partitioned region must be defined for the application that runs the transaction, but the data can be hosted in a remote member. |
- | **persistent regions** | Configure Geode to allow transactions on persistent regions. By default, the configuration does not allow transactions on persistent regions. Enable the use of transactions on persistent regions by setting the property `gemfire.ALLOW_PERSISTENT_TRANSACTIONS` to true. |
+ | **persistent regions** | Configure <%=vars.product_name%> to allow transactions on persistent regions. By default, the configuration does not allow transactions on persistent regions. Enable the use of transactions on persistent regions by setting the property `gemfire.ALLOW_PERSISTENT_TRANSACTIONS` to true. |
| **a mix of partitioned and replicated regions** | Make sure any replicated region involved in the transaction is hosted on every member that hosts the partitioned region data. All data for a single transaction must reside within a single host. |
- | **delta propagation** | Set the region attribute `cloning-enabled` to true. This lets Geode do conflict checks at commit time. Without this, the transaction will throw an `UnsupportedOperationInTransactionException ` exception. |
- | **global JTA transactions with only Geode cache transactions** | Set the region attribute `ignore-jta` to true for all regions that you do *not* want to participate in JTA global transactions. It is false by default. For instructions on how to run a JTA global transaction, see [JTA Global Transactions with Geode](JTA_transactions.html). |
+ | **delta propagation** | Set the region attribute `cloning-enabled` to true. This lets <%=vars.product_name%> do conflict checks at commit time. Without this, the transaction will throw an `UnsupportedOperationInTransactionException ` exception. |
+ | **global JTA transactions with only <%=vars.product_name%> cache transactions** | Set the region attribute `ignore-jta` to true for all regions that you do *not* want to participate in JTA global transactions. It is false by default. For instructions on how to run a JTA global transaction, see [JTA Global Transactions with <%=vars.product_name%>](JTA_transactions.html). |
3. **Update your cache event handler and transaction event handler implementations to handle your transactions.**
Cache event handlers may be used with transactions. Cache listeners are called after the commit, instead of after each cache operation, and the cache listeners receive conflated transaction events. Cache writers and loaders are called as usual, at the time of the operation.
@@ -85,6 +83,6 @@ This discussion centers on transactions on replicated and partitioned regions. I
5. **Review all of your code for compatibility with transactions.**
When you commit a transaction, while the commit is in process, the changes are visible in the distributed cache. This provides better performance than locking everything involved with the transaction updates, but it means that another process accessing data used in the transaction might get some data in the pre-transaction state and some in the post-transaction state.
- For example, suppose keys 1 and 2 are modified within a transaction, such that both values change from A to B. In another thread, it is possible to read key 1 with value B and key 2 with value A, after the commit begins, but before the commit completes. This is possible due to the nature of Geode reads. This choice sacrifices atomic visibility in favor of performance; reads do not block writes, and writes do not block reads.
+ For example, suppose keys 1 and 2 are modified within a transaction, such that both values change from A to B. In another thread, it is possible to read key 1 with value B and key 2 with value A, after the commit begins, but before the commit completes. This is possible due to the nature of <%=vars.product_name%> reads. This choice sacrifices atomic visibility in favor of performance; reads do not block writes, and writes do not block reads.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb b/geode-docs/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb
index 16a1397..40cf1a1 100644
--- a/geode-docs/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb
+++ b/geode-docs/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb
@@ -1,6 +1,4 @@
----
-title: How to Run a Geode Cache Transaction that Coordinates with an External Database
----
+<% set_title("How to Run a", product_name, "Cache Transaction that Coordinates with an External Database") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -19,9 +17,9 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Coordinate a Geode cache transaction with an external database by using CacheWriter/CacheListener and TransactionWriter/TransactionListener plug-ins, **to provide an alternative to using JTA transactions**.
+Coordinate a <%=vars.product_name%> cache transaction with an external database by using CacheWriter/CacheListener and TransactionWriter/TransactionListener plug-ins, **to provide an alternative to using JTA transactions**.
-There are a few things you should be careful about while working with Geode cache transactions and external databases:
+There are a few things you should be careful about while working with <%=vars.product_name%> cache transactions and external databases:
- When you set up the JDBC connection, make sure that auto-commit is disabled. For example, in Java:
@@ -40,15 +38,15 @@ There are a few things you should be careful about while working with Geode cach
max_prepared_transactions = 1 # 1 or more enables, zero (default) disables this feature.
```
-Use the following procedure to write a Geode cache transaction that coordinates with an external database:
+Use the following procedure to write a <%=vars.product_name%> cache transaction that coordinates with an external database:
-1. Configure Geode regions as necessary as described in [How to Run a Geode Cache Transaction](run_a_cache_transaction.html#task_f15_mr3_5k).
+1. Configure <%=vars.product_name%> regions as necessary as described in [How to Run a <%=vars.product_name%> Cache Transaction](run_a_cache_transaction.html#task_f15_mr3_5k).
2. Begin the transaction.
3. If you have not previously committed a previous transaction in this connection, start a database transaction by issuing a BEGIN statement.
-4. Perform Geode cache operations; each cache operation invokes the CacheWriter. Implement the CacheWriter to perform the corresponding external database operations.
+4. Perform <%=vars.product_name%> cache operations; each cache operation invokes the CacheWriter. Implement the CacheWriter to perform the corresponding external database operations.
5. Commit the transaction.
At this point, the TransactionWriter is invoked. The TransactionWriter returns a TransactionEvent, which contains all the operations in the transaction. Call PREPARE TRANSACTION within your TransactionWriter code.
-6. After a transaction is successfully committed in Geode, the TransactionListener is invoked. The TransactionListener calls COMMIT PREPARED to commit the database transaction.
+6. After a transaction is successfully committed in <%=vars.product_name%>, the TransactionListener is invoked. The TransactionListener calls COMMIT PREPARED to commit the database transaction.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/transaction_coding_examples.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/transaction_coding_examples.html.md.erb b/geode-docs/developing/transactions/transaction_coding_examples.html.md.erb
index 26aac45..bb13deb 100644
--- a/geode-docs/developing/transactions/transaction_coding_examples.html.md.erb
+++ b/geode-docs/developing/transactions/transaction_coding_examples.html.md.erb
@@ -21,24 +21,24 @@ limitations under the License.
This section provides several code examples for writing and executing transactions.
-- **[Basic Transaction Example](../../developing/transactions/transactions_overview.html)**
+- **[Basic Transaction Example](transactions_overview.html)**
This example operates on two replicated regions. It begins a transaction, updates one entry in each region, and commits the result.
-- **[Basic Suspend and Resume Transaction Example](../../developing/transactions/transaction_suspend_resume_example.html)**
+- **[Basic Suspend and Resume Transaction Example](transaction_suspend_resume_example.html)**
This example suspends and resumes a transaction.
-- **[Transaction Embedded within a Function Example](../../developing/transactions/transactional_function_example.html)**
+- **[Transaction Embedded within a Function Example](transactional_function_example.html)**
This example demonstrates a function that does transactional updates to Customer and Order regions.
-- **[Geode JTA Transaction Example](../../developing/transactions/transaction_jta_gemfire_example.html)**
+- **[<%=vars.product_name%> JTA Transaction Example](transaction_jta_gemfire_example.html)**
- An example code fragment shows how to run a JTA global transaction using Geode as the JTA transaction manager.
+ An example code fragment shows how to run a JTA global transaction using <%=vars.product_name%> as the JTA transaction manager.
-- **[JCA Resource Adapter Example](../../developing/transactions/jca_adapter_example.html)**
+- **[JCA Resource Adapter Example](jca_adapter_example.html)**
- This example shows how to use the JCA Resource Adapter in Geode .
+ This example shows how to use the JCA Resource Adapter in <%=vars.product_name%> .
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/transaction_event_management.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/transaction_event_management.html.md.erb b/geode-docs/developing/transactions/transaction_event_management.html.md.erb
index 9ec6b82..e9d84a9 100644
--- a/geode-docs/developing/transactions/transaction_event_management.html.md.erb
+++ b/geode-docs/developing/transactions/transaction_event_management.html.md.erb
@@ -46,11 +46,11 @@ results in these events stored in the CacheEvent list:
# At commit and after commit
-When the transaction is committed, Geode passes the `TransactionEvent` to the transaction writer local to the transactional view, if one is available. After commit, Geode :
+When the transaction is committed, <%=vars.product_name%> passes the `TransactionEvent` to the transaction writer local to the transactional view, if one is available. After commit, <%=vars.product_name%> :
- Passes the `TransactionEvent` to each installed transaction listener.
- Walks the `CacheEvent` list, calling all locally installed listeners for each operation listed.
- Distributes the `TransactionEvent` to all interested caches.
**Note:**
- For Geode and global JTA transactions, the `EntryEvent` object contains the Geode transaction ID. JTA transaction events do not contain the JTA transaction ID.
+ For <%=vars.product_name%> and global JTA transactions, the `EntryEvent` object contains the <%=vars.product_name%> transaction ID. JTA transaction events do not contain the JTA transaction ID.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/transaction_jta_gemfire_example.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/transaction_jta_gemfire_example.html.md.erb b/geode-docs/developing/transactions/transaction_jta_gemfire_example.html.md.erb
index 131d164..8f0b1ad 100644
--- a/geode-docs/developing/transactions/transaction_jta_gemfire_example.html.md.erb
+++ b/geode-docs/developing/transactions/transaction_jta_gemfire_example.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Geode JTA Transaction Example
----
+<% set_title(product_name, "JTA Transaction Example") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -19,7 +17,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-An example code fragment shows how to run a JTA global transaction using Geode as the JTA transaction manager.
+An example code fragment shows how to run a JTA global transaction using <%=vars.product_name%> as the JTA transaction manager.
The external data sources used in this transaction are configured in the `cache.xml` file. See [Configuring Database Connections Using JNDI](configuring_db_connections_using_JNDI.html#topic_A5E3A67C808D48C08E1F0DC167C5C494) for a configuration example.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/transaction_semantics.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/transaction_semantics.html.md.erb b/geode-docs/developing/transactions/transaction_semantics.html.md.erb
index 9a2e21e..3df3f20 100644
--- a/geode-docs/developing/transactions/transaction_semantics.html.md.erb
+++ b/geode-docs/developing/transactions/transaction_semantics.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Geode Cache Transaction Semantics
----
+<% set_title(product_name, "Cache Transaction Semantics") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -19,13 +17,13 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Geode transaction semantics differ in some ways from the Atomicity-Consistency-Isolation-Durability (ACID) semantics of traditional relational databases. For performance reasons, Geode transactions do not adhere to ACID constraints by default, but can be configured for ACID support as described in this section.
+<%=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.
-Geode 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. See [Committing Transactions](how_cache_transactions_work.html#concept_sbj_lj1_wk) for details on the two-phase commit protocol that implements the reservation system.
+<%=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. With the reservation system, an intersecting transaction is simply discarded. The serialization of obtaining locks is avoided. See [Committing Transactions](how_cache_transactions_work.html#concept_sbj_lj1_wk) for details on the two-phase commit protocol that implements the reservation system.
## <a id="transaction_semantics__section_7C287DA4A5134780B3199CE074E3F890" class="no-quick-link"></a>Consistency
@@ -33,9 +31,9 @@ Consistency requires that data written within a transaction must observe the key
## <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, Geode in its default configuration does not enforce read isolation. Geode transactions support repeatable read isolation, so once the committed value is read for a given key, it always returns that same value. If a transaction write, such as put or invalidate, deletes a value for a key that has already been read, subsequent reads return the transactional reference.
+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 repeatable read isolation, so once the committed value is read for a given key, it always returns that same value. If a transaction write, such as put or invalidate, deletes a value for a key that has already been read, subsequent reads return the transactional reference.
-In the default configuration, Geode 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 leading to a dirty read.
+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 leading to a dirty read.
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’:
@@ -45,7 +43,7 @@ This parameter causes read operations to succeed only when they read a consisten
## <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, Geode does not support on-disk or in-memory durability for transactions.
+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’.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/transactions/transactional_and_nontransactional_ops.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/transactions/transactional_and_nontransactional_ops.html.md.erb b/geode-docs/developing/transactions/transactional_and_nontransactional_ops.html.md.erb
index dc9f198..7cda91f 100644
--- a/geode-docs/developing/transactions/transactional_and_nontransactional_ops.html.md.erb
+++ b/geode-docs/developing/transactions/transactional_and_nontransactional_ops.html.md.erb
@@ -20,7 +20,7 @@ limitations under the License.
-->
-Between the begin operation and the commit or rollback operation are a series of ordinary Geode operations. When they are launched from within a transaction, the Geode operations can be classified into two types:
+Between the begin operation and the commit or rollback operation are a series of ordinary <%=vars.product_name%> operations. When they are launched from within a transaction, the <%=vars.product_name%> operations can be classified into two types:
- Transactional operations affect the transactional view
- Non-transactional operations do not affect the transactional view