http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/jca_adapter_example.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/jca_adapter_example.html.md.erb b/developing/transactions/jca_adapter_example.html.md.erb deleted file mode 100644 index 1e562cd..0000000 --- a/developing/transactions/jca_adapter_example.html.md.erb +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: JCA Resource Adapter Example ---- - -This example shows how to use the JCA Resource Adapter in Geode . - -``` pre -Hashtable env = new Hashtable(); -env.put(Context.INITIAL_CONTEXT_FACTORY, âweblogic.jndi.WLInitialContextFactoryâ); -env.put(Context.PROVIDER_URL, ât3://localhost:7001â); -Context ctx = new InitialContext(env); -UserTransaction utx = (UserTransaction) ctx.lookup(âjavax.transaction.UserTransactionâ); -utx.begin(); - // the XA Resource -javax.sql.DataSource ds = (DataSource) ctx.lookup(âderbyâ); -javax.sql.Connection derbyConn = ds.getConnection(); -Statement stmt = conn.createStatement(); -stmt.executeUpdate(âinsert into test values(2,4) â); - // do ConnectionFactory lookup -GFConnectionFactory cf = (GFConnectionFactory) ctx.lookup(âgfe/jcaâ); - - // Obtaining the connection begins the LocalTransaction. - // If this is absent, operations will not be part of any transaction. -GFConnection conn = cf.getConnection(); - -testRegion.put(âfooâ, âbar-â); -utx.commit(); - - // the connection can also be closed within the transaction -derbyConn.close(); -conn.close(); -``` - -
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/monitor_troubleshoot_transactions.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/monitor_troubleshoot_transactions.html.md.erb b/developing/transactions/monitor_troubleshoot_transactions.html.md.erb deleted file mode 100644 index 6cb1b6c..0000000 --- a/developing/transactions/monitor_troubleshoot_transactions.html.md.erb +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Monitoring and Troubleshooting Transactions ---- - -This topic covers errors that may occur when running transactions in Geode. - -<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. - -## <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. - -## <a id="monitor_troubleshoot_transactions__section_EA9277E6CFD7423F95BA4D04955FDE2A" class="no-quick-link"></a>Commit - -In a failed commit, the exception lists the first conflict that caused the failure. Other conflicts can exist, but are not reported. - -## Capacity Limits - -A transaction can create data beyond the capacity limit set in the regionâs eviction attributes. The capacity limit does not take effect until commit time. Then, any required eviction action takes place as part of the commit. - -## <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. - -## <a id="monitor_troubleshoot_transactions__section_8942ABA6F23C4ED58877C894B13F4F21" class="no-quick-link"></a>Transaction Exceptions - -The following sections list possible transaction exceptions. - -**Exceptions Indicating Transaction Failure** - -- **`TransactionDataNodeHasDepartedException`**. This exception means the transaction host has departed unexpectedly. Clients and members that run transactions but are not a transaction host can get this exception. You can avoid this by working to ensure your transaction hosts are stable and remain running when transactions are in progress. -- **`TransactionDataNotColocatedException`**. You will get this error if you try to run a transaction on data that is not all located in the same member. Partition your data so that a single member contains all data that will be accessed as part of a single transaction. See [Transactions and Partitioned Regions](cache_transactions_by_region_type.html#concept_ysk_xj1_wk) and [Understanding Custom Partitioning and Data Colocation](../partitioned_regions/custom_partitioning_and_data_colocation.html#custom_partitioning_and_data_colocation). -- **`TransactionDataRebalancedException`**. You get this error if your transactional data is moved to another member for rebalancing during the transaction. Manage your partitioned region data to avoid rebalancing during a transaction. See [Rebalancing Partitioned Region Data](../partitioned_regions/rebalancing_pr_data.html#rebalancing_pr_data). - -**Exceptions Indicating Unknown Transaction Outcome** - -- **`TransactionInDoubtException`**. Some of the transactional operations may have succeeded and some may have failed. This can happen to clients and to any member running a transaction on another data host. To manage this, you may want to install cache listeners in the members running the transaction code. Use the listeners to monitor and record the changes you receive from your transactions so you can recover as needed if you get this exception. - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/run_a_cache_transaction.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/run_a_cache_transaction.html.md.erb b/developing/transactions/run_a_cache_transaction.html.md.erb deleted file mode 100644 index 35ae027..0000000 --- a/developing/transactions/run_a_cache_transaction.html.md.erb +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: How to Run a Geode Cache Transaction ---- -<a id="task_f15_mr3_5k"></a> - - -This topic describes how to run a Geode 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. - -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. - -A transaction may not be nested within another transaction. An attempt to begin a nested transaction will throw an `IllegalStateException` exception. - -This discussion centers on transactions on replicated and partitioned regions. If you use non-replicated distributed regions, follow the guidelines for replicated regions. - -1. **Configure the cache copy-on-read behavior in the members hosting the transactional data, or perform cache updates that avoid in-place changes.** This allows the transaction manager to control when cache updates are visible outside the transaction. See [Setting Global Copy on Read](working_with_transactions.html#concept_vx2_gs4_5k). -2. **Configure your regions for transactions in the members hosting the transactional data.** - - | If you use... | then you should... | - |---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| - | **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. | - | **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). | - -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. - - Follow these additional guidelines when writing cache event handler callbacks: - - Make sure cache callbacks are transactionally aware, because a transactional operation could launch callbacks that are not transactional. - - Make sure cache listeners will operate properly, given entry event conflation. Two events for the same key are conflated by removing the existing event and queuing the new event. - - See [Using Cache Writer and Cache Listener Plug-Ins](working_with_transactions.html#concept_ysx_nf1_wk) for more information. - - Transaction event handlers are available. Transaction event handlers are cache-wide. You can install one transaction writer and any number of transaction listeners. Follow these guidelines: -<ul> - <li>Implement with synchronization for thread safety. Listener and writer handlers may be invoked at the same time by different threads for different transactions.</li> - <li>Keep transactional callback implementations lightweight, and avoid doing anything that might cause the callbacks to block.</li> -</ul> - See [Configuring Transaction Plug-In Event Handlers](working_with_transactions.html#concept_ocw_vf1_wk) for more information. - -4. **Write the transaction code.** For example: - - ``` pre - CacheTransactionManager txManager = - cache.getCacheTransactionManager(); - - try { - txManager.begin(); - // ... do work - txManager.commit(); - } catch (CommitConflictException conflict) { - // ... do necessary work for a transaction that failed on commit - } - ``` - - Follow these guidelines when writing the transaction: - - Start each transaction with a begin operation. - - Consider whether you will want to suspend and resume the transaction. If some operations should not be part of the transaction, you may want to suspend the transaction while performing non-transactional operations. After the non-transactional operations are complete, you can resume the transaction. See [Basic Suspend and Resume Transaction Example](transaction_suspend_resume_example.html#concept_40AAC4332DCE4E4EB60C4BA141B729A4) for an example. - - If your transaction operates on a mix of partitioned and replicated regions, do the first region operation on an entry of the partitioned region. This sets the host for the entire transaction. - - If you did not configure copy-on-read to true, be sure all cache updates avoid in-place changes. - - Take into account the behavior of transactional and non-transactional operations. All transactional operations that are run after the begin and before the commit or rollback are included in the transaction. - - End each transaction with a commit or a rollback. Do not leave any transaction in an uncommitted or unrolled back state. Transactions do not time out, so they will remain for the life of the application. - -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. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb b/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb deleted file mode 100644 index 474c139..0000000 --- a/developing/transactions/run_a_cache_transaction_with_external_db.html.md.erb +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: How to Run a Geode Cache Transaction that Coordinates with an External Database ---- - -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**. - -There are a few things you should be careful about while working with Geode cache transactions and external databases: - -- When you set up the JDBC connection, make sure that auto-commit is disabled. For example, in Java: - - ``` pre - Connection getConnection() throws SQLException { - Connection con = ... // create the connection - con.setAutoCommit(false); - return con; - } - ``` - -- The BEGIN statement, database operations and the PREPARE statement must all happen in the same connection session. In order to accomplish this, you will need to obtain the same JDBC connection session across multiple CacheWriter and TransactionWriter/TransactionListener invocations. One way to do this would be to look up the connection (from a user managed Map) based on `cacheTransactionManager.getTransactionId()`. -- Make sure that the prepare transaction feature is enabled in your external database. It is disabled in PostgreSQL by default. In PostgreSQL, the following property must be modified to enable it: - - ``` pre - 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: - -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). -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. -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. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transaction_coding_examples.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transaction_coding_examples.html.md.erb b/developing/transactions/transaction_coding_examples.html.md.erb deleted file mode 100644 index f442e06..0000000 --- a/developing/transactions/transaction_coding_examples.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Transaction Coding Examples ---- - -This section provides several code examples for writing and executing transactions. - -- **[Basic Transaction Example](../../developing/transactions/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)** - - This example suspends and resumes a transaction. - -- **[Transaction Embedded within a Function Example](../../developing/transactions/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)** - - An example code fragment shows how to run a JTA global transaction using Geode as the JTA transaction manager. - -- **[JCA Resource Adapter Example](../../developing/transactions/jca_adapter_example.html)** - - This example shows how to use the JCA Resource Adapter in Geode . - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transaction_event_management.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transaction_event_management.html.md.erb b/developing/transactions/transaction_event_management.html.md.erb deleted file mode 100644 index 9506f3d..0000000 --- a/developing/transactions/transaction_event_management.html.md.erb +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: How Transaction Events Are Managed ---- - -Transactional cache operations are handled somewhat differently inside transactions than out. - -# During the Transaction - -While the transaction is running, each transactional operation is passed to the cache writer local to the transactional view, if one is available. As with cache operations outside of transactions, the cache writer can abort the operation. Each operation the cache writer allows is applied to the transactional view in the cache and appended to the CacheEvent list in the TransactionEvent object. - -## Event Conflation - -The cache events are conflated, so if a key already has an event in the list, that event is removed and the current operation is added to the end of the list. So this series of calls inside a transaction: - -``` pre - Region.create (A, W); - Region.put (A, valX); - Region.put (B, valQ); - Region.invalidate (A); - Region.put (A, valY); -``` - -results in these events stored in the CacheEvent list: - -``` pre - put (B, valQ) - put (A, valY) -``` - -# 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 : - - 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. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transaction_jta_gemfire_example.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transaction_jta_gemfire_example.html.md.erb b/developing/transactions/transaction_jta_gemfire_example.html.md.erb deleted file mode 100644 index 6795158..0000000 --- a/developing/transactions/transaction_jta_gemfire_example.html.md.erb +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Geode JTA Transaction Example ---- - -An example code fragment shows how to run a JTA global transaction using Geode 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. - -``` pre -Region r = ...; // the region data source -ds = ...; // other data source - - try { - Context ctx = cache.getJNDIContext(); - Connection conn = null; - UserTransaction tx = (UserTransaction) ctx.lookup("java:/UserTransaction"); - tx.begin(); - conn = ds.getConnection(); - Statement stmt = conn.createStatement(); - String sqlSTR = "insert into " + tableName + " values (........ )"; - stmt.executeUpdate(sqlSTR); - r.put("key", "value"); - stmt.close(); - tx.commit(); - conn.close(); - } catch (NamingException e) { - // handle the exception - } -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transaction_semantics.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transaction_semantics.html.md.erb b/developing/transactions/transaction_semantics.html.md.erb deleted file mode 100644 index 58b3e47..0000000 --- a/developing/transactions/transaction_semantics.html.md.erb +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Geode Cache Transaction Semantics ---- - -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. - -## <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. - -## <a id="transaction_semantics__section_7C287DA4A5134780B3199CE074E3F890" class="no-quick-link"></a>Consistency - -Consistency requires that data written within a transaction must observe the key and value constraints established for the affected region. Note that validity of the transaction is the responsibility of the application. - -## <a id="transaction_semantics__section_126A24EC499D4CF39AE766A0B526A9A5" class="no-quick-link"></a>Isolation - -Isolation assures that operations will see either the pre-transaction state of the system or its post-transaction state, but not the transitional state that occurs while a transaction is in progress. Write operations in a transaction are always confirmed to ensure that stale values are not written. As a distributed cache-based system optimized for performance, 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. - -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. - -If an application requires the slower conventional isolation model (such that dirty reads of transitional states are not allowed), read operations must be encapsulated within transactions and the `gemfire.detectReadConflicts` parameter must be set to âtrueâ: - -`-Dgemfire.detectReadConflicts=true` - -This parameter causes read operations to succeed only when they read a consistent pre- or post-transactional state. If not, a `CommitConflictException` is thrown to the calling application. - -## <a id="transaction_semantics__section_F092E368724945BCBF8E5DCB36B97EB4" class="no-quick-link"></a>Durability - -Relational databases provide durability by using disk storage for recovery and transaction logging. As a distributed cache-based system optimized for performance, Geode does not support on-disk or in-memory durability for transactions. - -Applications can emulate the conventional disk-based durability model by setting the `gemfire.ALLOW_PERSISTENT_TRANSACTIONS` parameter to âtrueâ. - -`-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true` - -This allows permanent regions to participate in transactions, thus providing disk-based durability. See [Transactions and Persistent Regions](cache_transactions_by_region_type.html#concept_omy_341_wk) for more detail on the use of this parameter. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transaction_suspend_resume_example.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transaction_suspend_resume_example.html.md.erb b/developing/transactions/transaction_suspend_resume_example.html.md.erb deleted file mode 100644 index 40bc772..0000000 --- a/developing/transactions/transaction_suspend_resume_example.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Basic Suspend and Resume Transaction Example ---- - -This example suspends and resumes a transaction. - -``` pre - CacheTransactionManager txMgr = cache.getCacheTransactionManager(); - - txMgr.begin(); - region.put("key1", "value"); - TransactionId txId = txMgr.suspend(); - assert region.containsKey("key1") == false; - // do other operations that should not be - // part of a transaction - txMgr.resume(txId); - region.put("key2", "value"); - txMgr.commit(); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transactional_and_nontransactional_ops.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transactional_and_nontransactional_ops.html.md.erb b/developing/transactions/transactional_and_nontransactional_ops.html.md.erb deleted file mode 100644 index c2dd84b..0000000 --- a/developing/transactions/transactional_and_nontransactional_ops.html.md.erb +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Comparing Transactional and Non-Transactional Operations ---- - - -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: - -- Transactional operations affect the transactional view -- Non-transactional operations do not affect the transactional view - -An operation that acts directly on the cache does not usually act on the transactional view. - -- **[Transactional Operations](#transactional_operations)** - -- **[Non-Transactional Operations](#non_transactional_operations)** - -- **[Entry Operations](#entry_operations)** - -- **[Region Operations](#region_operations)** - -- **[Cache Operations](#cache_operations)** - -- **[No-Ops](#no-ops)** - -## <a id="transactional_operations" class="no-quick-link"></a>Transactional Operations - -The `CacheTransactionManager` methods are the only ones used specifically for cache operations. Otherwise, you use the same methods as usual. Most methods that run within a transaction affect the transactional view, and they do not change the cache until the transaction commits. Methods that behave this way are considered transactional operations. Transactional operations are classified in two ways: whether they modify the transactional view or the cache itself, and whether they create write conflicts with other transactions. - -In general, methods that create, destroy, invalidate, update, or read region entries are transactional operations. - -Transactional operations that can cause write conflicts are those that modify an entry, such as put, a load done to satisfy a get operation, create, delete, local delete, invalidate and local invalidate. - -Transactional read operations do not cause conflicts directly, but they can modify the transactional view. Read operations look for the entry in the transaction view first and then, if necessary, go to the cache. If the entry is returned by a cache read, it is stored as part of the transactional view. At commit time, the transaction uses the initial snapshot of the entry in the view to discover write conflicts. - -## <a id="non_transactional_operations" class="no-quick-link"></a>Non-Transactional Operations - -A few methods, when invoked within a transaction, have no effect on the transactional view, but they have an immediate effect on the cache. They are considered non-transactional operations. Often, non-transactional operations are administrative, such as `Region.destroy` and `Region.invalidate`. These operations are not supported within a transaction. If you call them, the system throws an exception of type `UnsupportedOperationInTransactionException`. - -## <a id="entry_operations" class="no-quick-link"></a>Entry Operations - -**Note:** -Transactional entry operations can be rolled back. - -| Operations | Methods | Transactional | Write Conflict | -|--------------------------------------|----------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|----------------| -| create | `Region.create, put, putAll, Map.put, putAll` | yes | yes | -| modify | `Region.put, putAll, Map.put, putAll, Region.Entry.setValue, Map.Entry.setValue` | yes | yes | -| load | `Region.get, Map.get` | yes | yes | -| creation or update using `netSearch` | `Region.get, Map.get` | yes | no | -| destroy: local and distributed | `Region.localDestroy, destroy, remove, Map.remove` | yes | yes | -| invalidate: local and distributed | `Region.localInvalidate, invalidate` | yes | yes | -| set user attribute | `Region.Entry.setUserAttribute` | yes | yes | -| read of a single entry | `Region.get, getEntry, containsKey, containsValue, containsValueForKey` | yes | no | -| read of a collection of entries | `Region.keySet, entrySet, values` | Becomes transactional when you access the keys or values within the collection. | no | - -Some transactional write operations also do a read before they write, and these can complete a transactional read even when the write fails. The following table of entry operations notes the conditions under which this can happen. - -**Note:** -These operations can add a snapshot of an entry to the transactionâs view even when the write operation does not succeed. - -| Operations | Methods | Reads Without Writing | -|-----------------------------------|--------------------------------------|---------------------------------------------------------------------------| -| create | `Region.create` | when it throws an `EntryExistsException` | -| destroy: local and distributed | `Region.localDestroy, destroy` | when it throws an `EntryNotFoundException` | -| invalidate: local and distributed | `Region.localInvalidate, invalidate` | when it throws an `EntryNotFoundException`or the entry is already invalid | - -## <a id="region_operations" class="no-quick-link"></a>Region Operations - -When you create a region in a transaction, any data from the getInitialImage operation goes directly into the cache, rather than waiting for the transaction to commit. - -| Operations | Methods | Affected | Write Conflict | -|-----------------------------------|--------------------------------------------------|-----------------------|----------------| -| destroy: local and distributed | `Region.localDestroyRegion, destroyRegion` | cache | yes | -| invalidate: local and distributed | `Region.localInvalidateRegion, invalidateRegion` | cache | yes | -| clear: local and distributed | `Region.localClear, clear, Map.clear` | cache and transaction | no | -| close | `Region.close` | cache | yes | -| mutate attribute | `Region.getAttributesMutator` methods | cache | no | -| set user attribute | `Region.setUserAttribute` | cache | no | - -## <a id="cache_operations" class="no-quick-link"></a>Cache Operations - -When you create a region in a transaction, any data from the getInitialImage operation goes directly into the cache, rather than waiting for the transaction to commit. - -| Operations | Methods | Affected State | Write Conflict | -|------------|----------------------------------|----------------|----------------| -| create | `createRegionFactory().create()` | committed | no | -| close | `close` | committed | yes | - -## <a id="no-ops" class="no-quick-link"></a>No-Ops - -Any operation that has no effect in a non-transactional context remains a no-op in a transactional context. For example, if you do two `localInvalidate` operations in a row on the same region, the second `localInvalidate` is a no-op. No-op operations do not: - -- Cause a listener invocation -- Cause a distribution message to be sent to other members -- Cause a change to an entry -- Cause any conflict - -A no-op can do a transactional read. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transactional_function_example.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transactional_function_example.html.md.erb b/developing/transactions/transactional_function_example.html.md.erb deleted file mode 100644 index 6539131..0000000 --- a/developing/transactions/transactional_function_example.html.md.erb +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Transaction Embedded within a Function Example ---- - -This example demonstrates a function that does transactional updates to Customer and Order regions. - -<a id="concept_22331B3DBFAB4C0BA95EF103BFB71257__section_73662C16E0BF4E4780F737C45DBD3137"></a> - -``` pre -/** - * This function does transactional updates to customer and order regions - */ -public class TransactionalFunction extends FunctionAdapter { - - private Random random = new Random(); - /* (non-Javadoc) - * @see org.apache.geode.cache.execute.FunctionAdapter#execute(org.apache.geode.cache.execute.FunctionContext) - */ - @Override - public void execute(FunctionContext context) { - RegionFunctionContext rfc = (RegionFunctionContext)context; - Region<CustomerId, String> custRegion = rfc.getDataSet(); - Region<OrderId, String> - orderRegion = custRegion.getRegionService().getRegion("order"); - - CacheTransactionManager - mgr = CacheFactory.getAnyInstance().getCacheTransactionManager(); - CustomerId custToUpdate = (CustomerId)rfc.getFilter().iterator().next(); - OrderId orderToUpdate = (OrderId)rfc.getArguments(); - System.out.println("Starting a transaction..."); - mgr.begin(); - int randomInt = random.nextInt(1000); - System.out.println("for customer region updating "+custToUpdate); - custRegion.put(custToUpdate, - "updatedCustomer_"+custToUpdate.getCustId()+"_"+randomInt); - System.out.println("for order region updating "+orderToUpdate); - orderRegion.put(orderToUpdate, - "newOrder_"+orderToUpdate.getOrderId()+"_"+randomInt); - mgr.commit(); - System.out.println("transaction completed"); - context.getResultSender().lastResult(Boolean.TRUE); - } - - /* (non-Javadoc) - * @see org.apache.geode.cache.execute.FunctionAdapter#getId() - */ - @Override - public String getId() { - return "TxFunction"; - } - -} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/transactions_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/transactions_overview.html.md.erb b/developing/transactions/transactions_overview.html.md.erb deleted file mode 100644 index bef97d7..0000000 --- a/developing/transactions/transactions_overview.html.md.erb +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Basic Transaction Example ---- - -This example operates on two replicated regions. It begins a transaction, updates one entry in each region, and commits the result. - -<a id="concept_F8D96C21C8444F99B47909CDEB86E60A__section_B6818C348224456387DEC5C9D3B5F250"></a> -If the commit fails, it will be due to a `CommitConflictException`, which implies that a concurrent access caused a change to one of the items operated on within this transaction. This code fragment catches the exception, and it repeats the transaction attempt until the commit succeeds. - -``` pre -Cache c = new CacheFactory().create(); - -Region<String, Integer> cash = c.createRegionFactory<String, Integer>() - .setDataPolicy(DataPolicy.REPLICATE) - .create("cash"); - -Region<String, Integer> trades = c.createRegionFactory<String, Integer>() - .setDataPolicy(DataPolicy.REPLICATE) - .create("trades"); - -CacheTransactionManager txmgr = c.getCacheTransactionManager(); -boolean commitConflict = false; -do { - try { - txmgr.begin(); - final String customer = "Customer1"; - final Integer purchase = Integer.valueOf(1000); - // Decrement cash - Integer cashBalance = cash.get(customer); - Integer newBalance = - Integer.valueOf((cashBalance != null ? cashBalance : 0) - - purchase); - cash.put(customer, newBalance); - // Increment trades - Integer tradeBalance = trades.get(customer); - newBalance = - Integer.valueOf((tradeBalance != null ? tradeBalance : 0) - + purchase); - - trades.put(customer, newBalance); - txmgr.commit(); - commitConflict = false; - } - catch (CommitConflictException conflict) { - commitConflict = true; - } -} while (commitConflict); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/turning_off_jta.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/turning_off_jta.html.md.erb b/developing/transactions/turning_off_jta.html.md.erb deleted file mode 100644 index 2ca75da..0000000 --- a/developing/transactions/turning_off_jta.html.md.erb +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Turning Off JTA Transactions ---- - -You can configure regions to not participate in any JTA global transaction. - -The `ignore-jta` region attribute is a boolean that tells the cache to ignore any in-progress JTA transactions when performing cache operations. It is primarily used for cache loaders, cache writers, and cache listeners that need to perform non-transactional operations on a region, such as caching a result set. It is set per region, so some regions can participate in JTA transactions, while others avoid participating in them. This example sets the `ignore-jta` region attribute in the `cache.xml` file. - -cache.xml: - -``` pre -<region name="bridge_region"> - <region-attributes scope="local" ignore-jta="true" statistics-enabled="true"/> - <cache-writer> . . . </cache-writer> - </region-attributes> -</region> -``` - -API: - -Using the API, you can turn off JTA transactions using `RegionFactory` and its method `setIgnoreJTA(boolean)`. The current setting for a region can be fetched from a region's `RegionAttributes` by using the `getIgnoreJTA` method. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/developing/transactions/working_with_transactions.html.md.erb ---------------------------------------------------------------------- diff --git a/developing/transactions/working_with_transactions.html.md.erb b/developing/transactions/working_with_transactions.html.md.erb deleted file mode 100644 index 6b30c66..0000000 --- a/developing/transactions/working_with_transactions.html.md.erb +++ /dev/null @@ -1,212 +0,0 @@ ---- -title: Working with Geode Cache Transactions ---- -<a id="topic_tx2_gs4_5k"></a> - - -This section contains guidelines and additional information on working with Geode and its cache transactions. - -- **[Setting Global Copy on Read](#concept_vx2_gs4_5k)** - -- **[Making a Safe Change Within a Transaction Using CopyHelper.copy](#concept_fdr_wht_vk)** - -- **[Transactions and Functions](#concept_ihn_zmt_vk)** - -- **[Using Queries and Indexes with Transactions](#concept_ty1_vnt_vk)** - -- **[Collections and Region.Entry Instances in Transactions](#concept_ksh_twz_vk)** - -- **[Using Eviction and Expiration Operations](#concept_vyt_txz_vk)** - -- **[Transactions and Consistent Regions](#transactions_and_consistency)** - -- **[Suspending and Resuming Transactions](#concept_u5b_ryz_vk)** - -- **[Using Cache Writer and Cache Listener Plug-Ins](#concept_ysx_nf1_wk)** - -- **[Configuring Transaction Plug-In Event Handlers](#concept_ocw_vf1_wk)** - -- **[How Transaction Events Are Managed](transaction_event_management.html)** - -## <a id="concept_vx2_gs4_5k" class="no-quick-link"></a>Setting Global Copy on Read - -As many entry operations return a reference to the cache entry, copy-on-read avoids problems within a transaction setting. To enable global copy-on-read for all reads, modify the `cache.xml` file or use the corresponding Java API call. - -Using cache.xml: - -``` pre -<cache lock-lease="120" lock-timeout="60" search-timeout="300" copy-on-read="true"> -``` - -API: - -``` pre -Cache c = CacheFactory.getInstance(system); - c.setCopyOnRead(true); -``` - -The copy-on-read attribute and the operations affected by the attribute setting are discussed in detail in [Managing Data Entries](../../basic_config/data_entries_custom_classes/managing_data_entries.html). - -## Making a Safe Change Within a Transaction Using CopyHelper.copy - -If `copy-on-read` is *not* globally set, and the cache uses replicated regions, explicitly make copies of the cache objects that are to be modified within a transaction. The `CopyHelper.copy` method makes copies: - -``` pre -CacheTransactionManager cTxMgr = cache.getCacheTransactionManager(); -cTxMgr.begin(); -Object o = (StringBuffer) r.get("stringBuf"); -StringBuffer s = (StringBuffer) CopyHelper.copy(o); -s.append("Changes unseen before commit. Read Committed."); -r.put("stringBuf", s); -cTxMgr.commit(); -``` - -## Transactions and Functions - -You can run a function from inside a transaction and you can nest a transaction within a function, as long as your combination of functions and transactions does not result in nested transactions. See [Function Execution](../function_exec/chapter_overview.html) for more about functions. - -A single transaction may contain multiple functions. - -If you are suspending and resuming a transaction with multiple function calls, all functions in the transaction must execute on the same member. - -See [Transaction Embedded within a Function Example](transactional_function_example.html#concept_22331B3DBFAB4C0BA95EF103BFB71257) for an example. - -## Using Queries and Indexes with Transactions - -Queries and indexes reflect the cache contents and ignore the changes made by ongoing transactions. If you do a query from inside a transaction, the query does not reflect the changes made inside that transaction. - -## Collections and Region.Entry Instances in Transactions - -Collections and region entries used in a transaction must be created inside the transaction. After the transaction has completed, the application can no longer use any region entry or collection or associated iterator created within the transaction. An attempted use outside of the transaction will throw an `IllegalStateException` exception. - -Region collection operations include `Region.keySet`, `Region.entrySet`, and `Region.values`. You can create instances of `Region.Entry` through the `Region.getEntry` operation or by looking at the contents of the result returned by a `Region.entrySet` operation. - -## Using Eviction and Expiration Operations - -Entry expiration and LRU eviction affect the committed state. They are not part of a transaction, and therefore they cannot be rolled back. - -## About Eviction - -LRU eviction operations do not cause write conflicts with existing transactions, despite destroying or invalidating entries. LRU eviction is deferred on entries modified by the transaction until the commit completes. Because anything touched by the transaction has had its LRU clock reset, eviction of those entries is not likely to happen immediately after the commit. - -When a transaction commits its changes in a region with distributed scope, the operation can invoke eviction controllers in the remote caches, as well as in the local cache. - -## Configure Expiration - -Local expiration actions do not cause write conflicts, but distributed expiration can cause conflicts and prevent transactions from committing in the members receiving the distributed operation. - -- When you are using transactions on local, preloaded or empty regions, make expiration local if possible. For every instance of that region, configure an expiration action of local invalidate or local destroy. In a cache.xml declaration, use a line similar to this: - - ``` pre - <expiration-attributes timeout="60" action="local-invalidate" /> - ``` - - In regions modified by a transaction, local expiration is suspended. Expiration operations are batched and deferred per region until the transaction completes. Once cleanup starts, the manager processes pending expirations. Transactions that need to change the region wait until the expirations are complete. - -- With partitioned and replicated regions, you cannot use local expiration. When you are using distributed expiration, the expiration is not suspended during a transaction, and expiration operations distributed from another member can cause write conflicts. In replicated regions, you can avoid conflicts by setting up your distributed system this way: - - Choose an instance of the region to drive region-wide expiration. Use a replicated region, if there is one. - - Configure distributed expiration only in that region instance. The expiration action must be either invalidate or destroy. In a `cache.xml` file declaration, use a line similar to this: - - ``` pre - <expiration-attributes timeout="300" action="destroy" /> - ``` - - - Run the transactions from the member in which expiration is configured. - -## Transactions and Consistent Regions - -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. - -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. - -## 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. - -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. - -When a transaction is resumed, the resuming thread assumes the transactional view. A transaction that is suspended on a member must be resumed on the same member. - -Before resuming a transaction, you may want to check if the transaction exists on the member and whether it is suspended. The `tryResume` method implements this check and resume as an atomic step. - -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. - -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. - -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. - -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. - -- `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. -- `CacheListener`. The cache listener callbacks - local and remote - are triggered after the transaction commits. The system sends the conflated transaction events, in the order they were stored. - -For more information on writing cache event handlers, see [Implementing Cache Event Handlers](../events/implementing_cache_event_handlers.html). - -## <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. - -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. - -**Note:** -You can also use transaction plug-in event handlers when running JTA global transactions. - -## TransactionWriter - -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. - -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. - -## Transaction Listeners - -When the transaction ends, its thread calls the transaction listener to perform the appropriate follow-up for successful commits, failed commits, or voluntary rollbacks. The transaction that caused the listener to be called no longer exists by the time the listener code executes. - -Transaction listeners have access to the transactional view and thus are not affected by non-transactional update operations. `TransactionListener` methods cannot make transactional changes or cause a rollback. They can, however, start a new transaction. Multiple transactions on the same cache can cause concurrent invocation of `TransactionListener` methods, so implement methods that do the appropriate synchronization of the multiple threads for thread-safe operation. - -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. - -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. - -**Note:** -The `cache-transaction-manager` allows listeners to be established. This attribute does not install a different transaction manager. - -Using cache.xml: - -``` pre -<cache search-timeout="60"> - <cache-transaction-manager> - <transaction-listener> - <class-name>com.company.data.MyTransactionListener</class-name> - <parameter name="URL"> - <string>jdbc:cloudscape:rmi:MyData</string> - </parameter> - </transaction-listener> - <transaction-listener> - . . . - </transaction-listener> - </cache-transaction-manager> - . . . - </cache> -``` - -Using the Java API: - -``` pre -CacheTransactionManager manager = cache.getCacheTransactionManager(); -manager.addListener(new LoggingTransactionListener()); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/.gitignore ---------------------------------------------------------------------- diff --git a/geode-docs/.gitignore b/geode-docs/.gitignore new file mode 100644 index 0000000..eaf0351 --- /dev/null +++ b/geode-docs/.gitignore @@ -0,0 +1,6 @@ +geode-book/Gemfile.lock +geode-book/final_app +geode-book/output +out +temp +*.bak http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/CONTRIBUTE.md ---------------------------------------------------------------------- diff --git a/geode-docs/CONTRIBUTE.md b/geode-docs/CONTRIBUTE.md new file mode 100644 index 0000000..dd97f47 --- /dev/null +++ b/geode-docs/CONTRIBUTE.md @@ -0,0 +1,63 @@ +# Contributing to the Project Geode Documentation + +Project Geode welcomes your contributions to the community's documentation efforts. You can participate by writing new content, reviewing and editing existing content, or fixing bugs. This document covers the following topics: + +- [How to Contribute](#contribute) +- [Document Source Files and Tools](#source_tools) +- [Writing Guidelines](#guidelines) + +[]() + +## How to Contribute + +We use the fork-and-pull collaboration method on GitHub: + +1. In your GitHub account, fork the gemfire/docs-geode-md repository. +2. Create a local clone of your fork. +3. Make changes and commit them in your fork. +4. In the gemfire/docs-geode-md repository, create a pull request. + +See [Using Pull Requests](https://help.github.com/articles/using-pull-requests/) on GitHub for more about the fork-and-pull collaboration method. + +[]() + +## Document Source Files and Tools + +Project Geode documentation source files are written in markdown. Image files include .gif and .png graphics and editable image files in the open source SVG format. + +- [Working with Markdown Files](#markdown) +- [Working with Images and Graphics](#images) + +[]() + +### Working with Markdown Files + +You can edit markdown files in any text editor. For more, read [Daring Fireball's Markdown Syntax page](https://daringfireball.net/projects/markdown/syntax). + +[]() + +### Working with Images and Graphics + +Image files in .gif or .png format are in the `images` directory in the Project Geode docs repo. Images in .svg format are in the `images_svg` directory. + +Most of the Project Geode image files have been converted to the open source SVG format. You can insert SVG images directly into an XML topic and modify images using a SVG editor. + +The Wikipedia page [Comparison of Vector Graphics Editors](http://en.wikipedia.org/wiki/Comparison_of_vector_graphics_editors) provides a list and comparison of commercial and free vector graphics editors. Note, however, that not all of these programs support the SVG format. + +[]() + +## Writing Guidelines + +The most important advice we can provide for working with the Project Geode docs is to spend some time becoming familiar with the existing source files and the structure of the project directory. In particular, note the following conventions and tips: + +- Top-level subdirectories organize topics into "books": basic_config, configuring, developing, etc. + +- Use lowercase characters for all file and directory names. Separate words in filenames with an underscore (`_`) character. + +- Use the `.md` file extension for topic files. + +- Add new topics to the existing directories by subject type. Only create a new directory if you are starting a new subject or a new book. + +- To start a new topic, you can make a copy of an existing file with similar content and edit it. + +- Use the appropriate document type for the content you are writing. Create multiple topics if you are writing overview, procedural, and reference content. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/README.md ---------------------------------------------------------------------- diff --git a/geode-docs/README.md b/geode-docs/README.md new file mode 100644 index 0000000..a018ca1 --- /dev/null +++ b/geode-docs/README.md @@ -0,0 +1,93 @@ +# Project Geode End-User Documentation + +The latest check-ins to `project-geode/docs` are automatically built and published to <http://geode-docs.cfapps.io>. + +Project Geode provides the full source for end-user documentation in markdown format. The markdown can be built into HTML using [Bookbinder](https://github.com/pivotal-cf/bookbinder). + +Bookbinder is a gem that binds together a unified documentation web application from markdown, html, and/or DITA source material. The source material for bookbinder must be stored either in local directories or in GitHub repositories. Bookbinder runs [middleman](http://middlemanapp.com/) to produce a Rackup app that can be deployed locally or as a Web application. + +This document contains instructions for building the local Geode documentation and publishing it to Cloud Foundry or Pivotal Web Services. It contains the sections: + +- [Bookbinder Usage](#usage) +- [Prerequisites](#prereq) +- [Building the Documentation](#building) +- [Publishing the Documentation](#publishing) +- [Getting More Information](#moreinfo) + +[]() + +## Bookbinder Usage + +Bookbinder is meant to be used from within a project called a **book**. The book includes a configuration file that describes which documentation repositories to use as source materials. Bookbinder provides a set of scripts to aggregate those repositories and publish them to various locations. + +For Geode, a preconfigured **book** is provided in the directory `/geode-book`. You can use this configuration to build HTML for project Geode on your local system. + +[]() + +## Prerequisites + +- Bookbinder requires Ruby version 2.0.0-p195 or higher. + +## Building the Documentation + +1. Begin by moving or copying the `/geode-book directory` to a directory that is parallel to `project-geode/docs`. For example: + + ``` + $ cd /repos/project-geode/docs + $ cp -r geode-book .. + $ cd ../geode-book + ``` + +2. The GemFile in the book directory already defines the `gem "bookbindery"` dependency. Make sure you are in the relocated book directory and enter: + + ``` + $ bundle install + ``` + +3. The installed `config.yml` file configures the Project Geode book for building locally. The installed file configures the local directory for the markdown source files. It uses the configuration: + + ``` + book_repo: project-geode/geode-book + public_host: localhost + + sections: + - repository: + name: gemfire/docs-geode-md + directory: docs-geode + subnav_template: geode-nav + + template_variables: + product_url: http://geode.incubator.apache.org + book_title: Project Geode Documentation + ``` + +4. Build the files locally using the installed `config.yml` file. Execute the command: + + ``` + $ bundle exec bookbinder bind local + ``` + + Bookbinder converts the markdown source into HTML, putting the final output in the `final_app` directory. + +5. To view the local documentation: + + ``` + $ cd final_app + $ rackup + ``` + + You can now view the local documentation at <http://localhost:9292> + +[]() + +## Publishing the Documentation + +Because the `final_app` directory contains the full output of the HTML conversion process, you can easily publish this directory as a hosted Web application. + +[]() + +## Getting More Information + +Bookbinder provides additional functionality to construct books from multiple Github repos, to perform variable substitution, and also to automatically build documentation in a continuous integration pipeline. For more information, see <https://github.com/pivotal-cf/bookbinder>. + +The latest check-ins to `gemfire/docs-geode-md` are automatically built and published to <http://geode-docs.cfapps.io>. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/about_geode.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/about_geode.html.md.erb b/geode-docs/about_geode.html.md.erb new file mode 100644 index 0000000..3117eb4 --- /dev/null +++ b/geode-docs/about_geode.html.md.erb @@ -0,0 +1,9 @@ +--- +title: Apache Geode 1.0.0-incubating Documentation +--- + +This documentation describes product concepts and provides complete setup instructions for Apache Geode 1.0.0-incubating. Source files and instructions on how to build this documentation are available at [https://github.com/project-geode/docs](https://github.com/project-geode/docs) and [https://github.com/project-geode/docs/blob/master/README.md](https://github.com/project-geode/docs/blob/master/README.md). + +You can also find additional documentation about Geode on the **Apache Geode Wiki**: [https://cwiki.apache.org/confluence/display/GEODE/Index](https://cwiki.apache.org/confluence/display/GEODE/Index). + + http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/basic_config/book_intro.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/book_intro.html.md.erb b/geode-docs/basic_config/book_intro.html.md.erb new file mode 100644 index 0000000..1b6114e --- /dev/null +++ b/geode-docs/basic_config/book_intro.html.md.erb @@ -0,0 +1,23 @@ +--- +title: Basic Configuration and Programming +--- + +*Basic Configuration and Programming* describes how to configure distributed system and cache properties for your Apache Geode installation. For your applications, it provides guidance for writing code to manage your cache and distributed system connection, data regions, and data entries, including custom classes. + +- **[Distributed System and Cache Configuration](../basic_config/config_concepts/chapter_overview.html)** + + To work with your Apache Geode applications, you use a combination of configuration files and application code. + +- **[Cache Management](../basic_config/the_cache/chapter_overview.html)** + + The Geode cache is the entry point to Geode caching management. Geode provides different APIs and XML configuration models to support the behaviors of different members. + +- **[Data Regions](../basic_config/data_regions/chapter_overview.html)** + + The region is the core building block of the Apache Geode distributed system. All cached data is organized into data regions and you do all of your data puts, gets, and querying activities against them. + +- **[Data Entries](../basic_config/data_entries_custom_classes/chapter_overview.html)** + + The data entry is the key/value pair where you store your data. You can manage your entries individually and in batches. To use domain objects for your entry values and keys, you need to follow Apache Geode requirements for data storage and distribution. + + http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/basic_config/config_concepts/chapter_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/config_concepts/chapter_overview.html.md.erb b/geode-docs/basic_config/config_concepts/chapter_overview.html.md.erb new file mode 100644 index 0000000..8f3fa6d --- /dev/null +++ b/geode-docs/basic_config/config_concepts/chapter_overview.html.md.erb @@ -0,0 +1,23 @@ +--- +title: Distributed System and Cache Configuration +--- + +To work with your Apache Geode applications, you use a combination of configuration files and application code. + +- **[Distributed System Members](../../basic_config/config_concepts/distributed_system_member_configuration.html)** + + Distributed system members are programs that connect to a Geode distributed system. You configure members to belong to a single distributed system, and you can optionally configure them to be clients or servers to members in other distributed systems, and to communicate with other distributed systems. + +- **[Setting Properties](../../basic_config/gemfire_properties/setting_distributed_properties.html)** + + Geode provides a default distributed system configuration for out-of-the-box systems. To use non-default configurations and to fine-tune your member communication, you can use a mix of various options to customize your distributed system configuration. + +- **[Options for Configuring the Cache and Data Regions](../../basic_config/the_cache/setting_cache_properties.html)** + + To populate your Apache Geode cache and fine-tune its storage and distribution behavior, you need to define cached data regions and provide custom configuration for the cache and regions. + +- **[Local and Remote Membership and Caching](../../basic_config/config_concepts/local_vs_remote.html)** + + For many Apache Geode discussions, you need to understand the difference between local and remote membership and caching. + + http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb new file mode 100644 index 0000000..5da27bc --- /dev/null +++ b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb @@ -0,0 +1,34 @@ +--- +title: Distributed System Members +--- + +Distributed system members are programs that connect to a Geode distributed system. You configure members to belong to a single distributed system, and you can optionally configure them to be clients or servers to members in other distributed systems, and to communicate with other distributed systems. + +## <a id="distributed_system_member_configuration__section_326B2609B67E4FBE9BF2074C3B211E50" class="no-quick-link"></a>Member Overview + +Distributed system members (or simply "members") connect to the Geode system when they create the Geode data cache. The members' distributed system is configured through Geode properties. See [gemfire.properties and gfsecurity.properties (Geode Properties)](../../reference/topics/gemfire_properties.html). Geode properties specify all necessary information for system member startup, initialization, and communication. + +**Note:** +You cannot change a member's properties while the member is connected to the distributed system. + +Use the properties to define: + +- How to find and communicate with other system members +- How to perform logging and statistics activities +- Which persistent configuration or `cache.xml` file to use for cache and data region initialization +- Other options, including event conflation, how to handle network loss, and security settings + +## <a id="distributed_system_member_configuration__section_E755E9E4A31149C980561D617A99A002" class="no-quick-link"></a>Distributed System Membership and System Topologies + +Every Geode process is a member of a distributed system, even if the distributed system is defined as standalone, with just one member. You can run an individual distributed system in isolation or you can combine systems for vertical and horizontal scaling. See [Topology and Communication General Concepts](../../topologies_and_comm/topology_concepts/chapter_overview.html). + +- **Peer-to-Peer Distributed Systems**. Members that define the same member discovery properties belong to the same distributed system and are peers to one another. +- **Client/Server Installations**. The client/server topology uses relationships that you configure between members of multiple distributed systems. You configure some or all of the peers in one distributed system to act as cache servers to clients connecting from outside the system. Each server can host many client processes, managing cache access for all in an efficient, vertically hierarchical cache configuration. You configure the client applications to connect to the servers, using a client cache configuration. Clients run as members of standalone Geode distributed systems, with no peers, so all data updates and requests go to the servers. + +## **Multi-site Installations** + +The multi-site topology uses relationships that you configure between members of multiple distributed systems. Through this configuration, you loosely couple two or more distributed systems for automated data distribution. This is usually done for sites at geographically separate locations. You configure a subset of peers in each distributed system site with gateway senders and/or gateway receivers to manage events that are distributed between the sites. + +In the context of a single distributed system, unless otherwise specified, remote members refers to other members of the same distributed system. In client/server and multi-site installations, remote generally refers to members in other distributed systems. For example, all servers are remote to the clients that connect to them. Each client runs standalone, with connections only to the server tier, so all servers and their other clients are remote to the individual client. All gateway receivers are remote to the gateway senders that connect to them from other distributed systems,and to those gateway sendersâ peers. + + http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/basic_config/config_concepts/local_vs_remote.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/config_concepts/local_vs_remote.html.md.erb b/geode-docs/basic_config/config_concepts/local_vs_remote.html.md.erb new file mode 100644 index 0000000..f48b459 --- /dev/null +++ b/geode-docs/basic_config/config_concepts/local_vs_remote.html.md.erb @@ -0,0 +1,12 @@ +--- +title: Local and Remote Membership and Caching +--- + +For many Apache Geode discussions, you need to understand the difference between local and remote membership and caching. + +<a id="local_vs_remote_member_and_cache__section_5535DC4C94494B6A9B106DA39F63A439"></a> +Discussions of Geode membership and caching activities often differentiate between local and remote. Local caching always refers to the central member under discussion, if there is one such obvious member, and remote refers to other members. If there is no clear, single local member, the discussion assigns names to the members to differentiate. Operations, data, configuration, and so forth that are "local to member Q" are running or resident inside the member Q process. Operations, data, configuration, and so on, that are "remote to member Q" are running or resident inside some other member. + +The local cache is the cache belonging to the local member. All other caches are remote, whether in other members of the same distributed system or in different distributed systems. + + http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ccc2fbda/geode-docs/basic_config/data_entries_custom_classes/chapter_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/data_entries_custom_classes/chapter_overview.html.md.erb b/geode-docs/basic_config/data_entries_custom_classes/chapter_overview.html.md.erb new file mode 100644 index 0000000..565cd87 --- /dev/null +++ b/geode-docs/basic_config/data_entries_custom_classes/chapter_overview.html.md.erb @@ -0,0 +1,15 @@ +--- +title: Data Entries +--- + +The data entry is the key/value pair where you store your data. You can manage your entries individually and in batches. To use domain objects for your entry values and keys, you need to follow Apache Geode requirements for data storage and distribution. + +- **[Managing Data Entries](../../basic_config/data_entries_custom_classes/managing_data_entries.html)** + + Program your applications to create, modify, and manage your cached data entries. + +- **[Requirements for Using Custom Classes in Data Caching](../../basic_config/data_entries_custom_classes/using_custom_classes.html)** + + Follow these guidelines to use custom domain classes for your cached entry keys and values. + +
