Unless otherwise noted, these settings are used both for the legacy (Oracle Types or Oracle-only) backing store and for the JDBC backing store. See JDBC Backing Store Configuration and Appendix A, Setting up an Oracle-Only Backing Store for setup details.
Note: Individual entities can be set to not use the backing store. See Metadata Properties for Entities (Events and Concepts).If not checked, either the cluster does not have a backing store or the backing store is temporarily disabled.To override this default behavior, add the following properties to the property sheet and set their values as appropriate:See Cluster Tab — Cache Manager — Backing Store Properties for more on these properties. com.tibco.be.jdbcstore.BECoherenceJdbcStore — for JDBC backing store.com.tibco.be.oracle.BECoherenceOracleStore — for legacy Oracle backing store.the cache-aside database write method is used, and a limited cache is enabled by default. You can override these by adding the following properties to the property sheet:See Cluster Tab — Cache Manager — Backing Store Properties for more on these properties. Used for JDBC backing store only. Select which of the supported DBMS products to use: oracle or sqlserver.Default is oracle. Used for JDBC backing store only. If Oracle Database is used, you have the option of using either the internal pooling implementation, or Oracle Database’s implementation. Possible values are as follows:jdbc Use the internal pooling mechanism.oracle For Oracle Database only. Use Oracle’s pooling mechanism (see the class OracleConnectionCacheManager in the package oracle.jdbc.pool). When set to oracle then the BusinessEvents pooling property values are used to set their corresponding to Oracle Database properties.Default is oracle. Used only if the Backing Store Enabled checkbox is checked. Ignored otherwise (internally set to false). When JDBC backing store is used, cache-aside is used automatically, and this property is ignored.
• Write-behind Writes data to the cache and then to the backing store. One write-behind thread is used for each entity type. See also tangosol.coherence.distributed.threads which is set in the Processing Units tab (see Processing Units Tab Settings and Properties.
• Cache-aside Writes data to the cache and at the same time to the backing store. User controls are available for the threading and queue size. See Post RTC Options — Cache-aside and Write-behind. Try running with default pool values and monitor the behavior. Using more connections improves runtime performance and can also speed up recovery in the event of a failure.Pool settings are used only if Enforce Pools is checked. Specifies the project path, that is, the path from the project root to the JDBC Connection resource, to define the connection to the backing store. For example: Used by JDBC backing store only if Cluster tab > Backing Store > Strategy is set to oracle. Also used by the Oracle-only legacy backing store.Oracle Strategy If Oracle Database Strategy settings are used, this property corresponds to the OracleConnectionCacheManager class property MinLimit. Maximum number of JDBC connections in the JDBC connection pool used for the backing store. Connections do not exceed the maximum.The value of this property overrides the value of the Max Connections setting in the JDBC Connection resource.Oracle Strategy If Oracle Database Strategy settings are used, this property corresponds to the OracleConnectionCacheManager class property MaxLimit. Specifies the initial size of the JDBC connection pool used for the backing store, when it is created on startup. For example:Oracle Strategy If Oracle Database Strategy settings are used, this property corresponds to the OracleConnectionCacheManager class property InitialLimit.
Copyright © TIBCO Software Inc. All Rights Reserved.