This appendix provides a detailed reference of the cache configuration deployment descriptor elements and includes a brief overview of the descriptor.
This appendix includes the following sections:
The cache configuration deployment descriptor specifies the various types of caches that can be used within a cluster. The name and location of the descriptor is specified in the operational deployment descriptor and defaults to coherence-cache-config.xml. A sample configuration descriptor is packaged in the root of the coherence.jar library and is used unless a custom coherence-cache-config.xml file is found before the coherence.jar file within the application's classpath. All cluster members should use identical cache configuration descriptors if possible.
The cache configuration deployment descriptor schema is defined in the coherence-cache-config.xsd file, which imports the coherence-cache-config-base.xsd file, which, in turn, imports the coherence-config-base.xsd file. These XSD files are located in the root of the coherence.jar library and at the following Web URL:
http://xmlns.oracle.com/coherence/coherence-cache-config/1.2/coherence-cache-config.xsd
The <cache-config> element is the root element of the cache configuration descriptor and typically includes an XSD and Coherence namespace reference and the location of the coherence-cache-config.xsd file. For example:
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">
Notes:
The schema located in the coherence.jar library is always used at run time even if the xsi:schemaLocation attribute references the Web URL.
The xsi:schemaLocation attribute can be omitted to disable schema validation.
When deploying Coherence into environments where the default character set is EBCDIC rather than ASCII, ensure that the deployment descriptor file is in ASCII format and is deployed into its run-time environment in the binary format.
Table B-1 lists all non-terminal cache configuration deployment descriptor elements.
Table B-1 Non-Terminal Cache Configuration Elements
Used in: proxy-scheme
The acceptor-config element specifies the configuration information for a TCP/IP or HTTP (for REST) connection acceptor. The connection acceptor is used by a proxy service to enable Coherence*Extend clients to connect to the cluster and use cluster services without having to join the cluster.
Table B-2 describes the subelements of the acceptor-config element.
Table B-2 acceptor-config Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the configuration information for a connection acceptor that accepts connections from remote REST clients over HTTP. This element cannot be used together with the |
|
|
Optional |
Specifies the configuration information for a connection acceptor that enables Coherence*Extend clients to connect to the cluster over TCP/IP. This element cannot be used together with the |
|
|
Optional |
Specifies the configuration information for a connection acceptor that accepts connections from remote memcached clients over TCP/IP. This element cannot be used together with the |
|
|
Optional |
Specifies the configuration information that is used to regulate client-to-cluster connection resource usage. |
|
|
Optional |
Specifies the configuration information used by the connection acceptor to detect dropped client-to-cluster connections. |
|
|
< |
Optional |
Contains the list of filter names to be used by this connection acceptor. For example, specifying
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
|
|
Optional |
Specifies the class configuration information for a
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>my-pof-types.xml</param-value>
</init-param>
</init-params>
</serializer>
|
|
|
< |
Optional |
The maximum number of simultaneous connections allowed by this connection acceptor. Valid values are positive integers and zero. A value of zero implies no limit. The default value is zero. |
Used in: name-service-addresses, remote-addresses, tcp-acceptor, memcached-acceptor
The address-provider element specifies either socket address information (IP, or DNS name, and port) or an implementation of the com.tangosol.net.AddressProvider interface. The interface offers a programmatic way to define socket addresses.
The preferred approach is to reference an address provider definition that is included in an operational override file. This approach decouples deployment configuration from application configuration. However, socket addresses can also be configured in-line and is typical during development. For additional details on defining address providers that can be referenced, see "address-provider".
The following example references an address provider definition that contains the socket address to which a TCP/IP acceptor is bound.
<tcp-acceptor>
<address-provider>ap2</address-provider>
</tcp-acceptor>
The following example references an address provider definition that contains the socket address of a TCP/IP acceptor on the cluster.
<tcp-initiator>
<remote-addresses>
<address-provider>ap3</address-provider>
</remote-addresses>
</tcp-initiator>
The following example references an address provider definition that contains the socket address of a name service TCP/IP acceptor on the cluster.
<tcp-initiator>
<name-service-addresses>
<address-provider>ap4</address-provider>
</name-service-addresses>
</tcp-initiator>
The following example references an address provider definition that contains the socket address to which a TCP/IP memcached acceptor is bound.
<memcached-acceptor>
<address-provider>ap5</address-provider>
</memcached-acceptor>
Table B-3 describes the subelements of the address-provider element.
Table B-3 address-provider Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the fully qualified name of a class that implements the This element cannot be used with the |
|
< |
Optional |
Specifies the fully qualified name of a factory class for creating address provider instances. The instances must implement the This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Specifies initialization parameters which are accessible by implementations that include a public constructor with a matching signature. Initialization parameters can be specified for both the |
|
|
Optional |
Specifies the address (IP, or DNS name, and port) to which a socket is bound. This element cannot be used if an address provider implementation is defined using the |
Used in: external-scheme, paged-external-scheme.
The async-store-manager element adds asynchronous write capabilities to other store manager implementations. Supported store managers include:
custom-store-manager—allows definition of custom implementations of store managers
bdb-store-manager—uses Berkeley Database JE to implement an on disk cache
nio-file-manager—uses NIO to implement memory-mapped file based cache
nio-memory-manager—uses NIO to implement an off JVM heap, in-memory cache
Note:
The NIO memory manager implementation is deprecated. Current implementation should use a journal binary store instead. See "Using the Elastic Data Feature to Store Data".This store manager is implemented by the com.tangosol.io.AsyncBinaryStoreManager class.
Table B-4 describes the subelements of the async-store-manager element.
Table B-4 async-store-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies a custom implementation of an asynchronous store manager. Any custom implementation must extend the |
|
Optional |
Specifies initialization parameters, for use in custom async-store-manager implementations. |
|
|
Optional |
Configures the external cache to use Berkeley Database JE on disk databases for cache storage. |
|
|
Optional |
Configures the external cache to use a custom storage manager implementation. |
|
|
Optional |
Configures the external cache to use a memory-mapped file for cache storage. |
|
|
Optional |
Configures the external cache to use an off JVM heap, memory region for cache storage. |
|
|
< |
Optional |
Specifies the maximum number of bytes that are queued to be written asynchronously. Setting the value to zero indicates that the implementation default for the maximum number of bytes is used. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. Valid values are any positive memory sizes and zero. The default value is 4MB. |
Used in: tcp-acceptor.
This element contains the collection of IP addresses of TCP/IP initiator hosts that are allowed to connect to the cluster using a TCP/IP acceptor. If this collection is empty no constraints are imposed. Any number of host-address and host-range elements may be specified.
Table B-5 describes the subelements of the authorized-hosts element.
Table B-5 authorized-hosts Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies an IP address or host name. If any are specified, only hosts with specified host-addresses or within the specified host-ranges are allowed to join the cluster. The content override attributes |
|
|
Optional |
Specifies a range of IP addresses. If any are specified, only hosts with specified host-addresses or within the specified host-ranges are allowed to join the cluster. |
|
|
Optional |
Specifies class configuration information for a |
Used in: near-scheme, overflow-scheme
Table B-6 describes the subelements of the back-scheme element.
Table B-6 back-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Defines a cache scheme where storage of cache entries is partitioned across the cluster nodes. |
|
|
Optional |
Defines a replicated cache scheme which uses optimistic rather then pessimistic locking. |
|
|
Optional |
Defines a cache scheme where each cache entry is stored on all cluster nodes. |
|
|
Optional |
Defines a cache scheme where storage of cache entries is partitioned across the cluster nodes with transactional guarantees. |
|
|
Optional |
Local cache schemes define in-memory "local" caches. Local caches are generally nested within other cache schemes, for instance as the front-tier of a near scheme. |
|
|
Optional |
External schemes define caches which are not JVM heap based, allowing for greater storage capacity. |
|
|
Optional |
As with external-scheme, |
|
|
Optional |
Class schemes provide a mechanism for instantiating an arbitrary Java object for use by other schemes. The scheme which contains this element dictates what class or interface(s) must be extended. |
|
|
Optional |
Specifies a scheme that uses journaling to store data to flash memory. |
|
|
Optional |
Specifies a scheme that uses journaling to store data to RAM memory. |
|
|
Optional |
Defines a cache scheme that enables caches to be accessed from outside a Coherence cluster by using Coherence*Extend. |
Used in: distributed-scheme, optimistic-scheme, replicated-scheme
Specifies what type of cache is used within the cache server to store entries.
When using an overflow-based backing map, it is important that the corresponding backup-storage be configured for overflow (potentially using the same scheme as the backing-map). See "Partitioned Cache with Overflow" for an example configuration.
Note:
Thepartitioned subelement is only used if the parent element is the distributed-scheme element.Table B-7 describes the subelements of the backing-map-scheme element.
Table B-7 backing-map-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies whether the enclosed backing map is a
Valid values are |
|
Optional |
Local cache schemes define in-memory "local" caches. Local caches are generally nested within other cache schemes, for instance as the front-tier of a near scheme. |
|
|
Optional |
External schemes define caches which are not JVM heap based, allowing for greater storage capacity. |
|
|
Optional |
As with external-scheme, |
|
|
Optional |
The |
|
|
Optional |
Class schemes provide a mechanism for instantiating an arbitrary Java object for use by other schemes. The scheme which contains this element dictates what class or interface(s) must be extended. |
|
|
Optional |
Specifies a scheme that uses journaling to store data to flash memory. |
|
|
Optional |
Specifies a scheme that uses journaling to store data to RAM memory. |
|
|
Optional |
The read-write-backing-map-scheme defines a backing map which provides a size limited cache of a persistent store. |
Used in: distributed-scheme.
The backup-storage element specifies the type and configuration of backup storage for a partitioned cache.
Table B-8 describes the subelements of the backup-storage element.
Table B-8 backup-storage Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the type of the storage used to hold the backup data. Legal values are:
The preconfigured system property override is |
|
< |
Optional |
Specifies the initial buffer size in bytes. The class name is only applicable if the (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
|
< |
Optional |
Specifies the initial buffer size in bytes. The class name is only applicable if the (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
|
< |
Optional |
Specifies the path name for the directory that the disk persistence manager ( |
|
< |
Optional |
Specifies a class name for the custom storage implementation. The class name is only applicable if the |
|
< |
Optional |
Specifies a scheme name for the |
Used in: external-scheme, paged-external-scheme, async-store-manager.
Note:
Berkeley Database JE Java class libraries are required to use abdb-store-manager, see the Berkeley Database JE product page for additional information.
http://www.oracle.com/technology/documentation/berkeley-db/je/index.html
The BDB store manager is used to define external caches which uses Berkeley Database JE on disk embedded databases for storage. See the examples of Berkeley-based store configurations in "Persistent Cache on Disk" and "In-memory Cache with Disk Based Overflow".
This store manager is implemented by the com.tangosol.io.bdb.BerkeleyDBBinaryStoreManager class, and produces BinaryStore objects implemented by the com.tangosol.io.bdb.BerkeleyDBBinaryStore class.
Table B-9 describes the subelements of the bdb-store-manager element.
Table B-9 bdb-store-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies a custom implementation of the Berkeley Database |
|
Optional |
Specifies additional Berkeley DB configuration settings. See the Berkeley DB Configuration instructions: Also used to specify initialization parameters, for use in custom implementations. |
|
|
< |
Optional |
Specifies the path name to the root directory where the Berkeley Database JE store manager stores files. If not specified or specified with a non-existent directory, a temporary directory in the default location is used. |
|
< |
Optional |
Specifies the name for a database table that the Berkeley Database JE store manager uses to store data in. Specifying this parameter causes the When specifying this property, it is recommended to use the |
Used in: operation-bundling.
The bundle-config element specifies the bundling strategy configuration for one or more bundle-able operations.
Table B-10 describes the subelements of the bundle-config element.
Table B-10 bundle-config Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the operation name for which calls performed concurrently on multiple threads are "bundled" into a functionally analogous "bulk" operation that takes a collection of arguments instead of a single one. Valid values depend on the bundle configuration context. For the <
For the <
In all cases there is a pseudo operation named |
|
< |
Optional |
Specifies the bundle size threshold. When a bundle size reaches this value, the corresponding "bulk" operation is invoked immediately. This value is measured in context-specific units. Valid values are zero (disabled bundling) or positive values. The default value is zero. |
|
< |
Optional |
Specifies the maximum amount of time in milliseconds that individual execution requests are allowed to be deferred for a purpose of "bundling" them and passing into a corresponding bulk operation. If the preferred-size threshold is reached before the specified delay, the bundle is processed immediately. Valid values are positive numbers. The default value is 1. |
|
< |
Optional |
Specifies the minimum number of threads that must be concurrently executing individual (non-bundled) requests for the bundler to switch from a pass-through to a bundling mode. Valid values are positive numbers. The default value is 4. |
|
< |
Optional |
Specifies whether the auto adjustment of the preferred-size value (based on the run-time statistics) is allowed. Valid values are |
Root Element
The cache-config element is the root element of the cache configuration descriptor, coherence-cache-config.xml. For more information on this document, see "Cache Configuration Deployment Descriptor".
At a high level, a cache configuration consists of cache schemes and cache scheme mappings. Cache schemes describe a type of cache, for instance a database backed, distributed cache. Cache mappings define what scheme to use for a given cache name.
Table B-11 describes the subelements of the cache-config element.
Table B-11 cache-config Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
The use of the |
|
|
Optional |
Defines factory wide default settings. |
|
Optional |
Specifies any number of event interceptors that process events. Specifiying the |
|
|
Required |
Specifies the caching-scheme that is used for caches, based on the cache's name. |
|
|
Required |
Defines the available caching-schemes for use in the cluster. |
Used in: caching-scheme-mapping
Each cache-mapping element specifies the caching-schemes which are to be used for a given cache name or cache name pattern used by an application.
Table B-12 describes the subelements of the cache-mapping element.
Table B-12 cache-mapping Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
Specifies a cache name or name pattern. The name is unique within a cache factory. The following cache name patterns are supported:
If a cache name can be matched to multiple cache mappings, then exact matches are selected over wildcard matches. If no exact match is specified, then the last matching wildcard pattern (based on the order in which they are defined in the file) is selected. |
|
< |
Required |
Contains the caching scheme name. The name is unique within a configuration file. Caching schemes are configured in the caching-schemes element. |
|
Optional |
Allows specifying replaceable cache scheme parameters. During cache scheme parsing, any occurrence of any replaceable parameter in format
<cache-mapping>
<cache-name>My*</cache-name>
<scheme-name>my-scheme</scheme-name>
<init-params>
<init-param>
<param-name>cache-loader</param-name>
<param-value>com.acme.MyCacheLoader</param-value>
</init-param>
<init-param>
<param-name>size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>
For any cache name match |
|
|
Optional |
Specifies any number of event interceptors that process events for a specific cache. |
Used in: proxy-config
The cache-service-proxy element contains the configuration information for a cache service proxy that is managed by a proxy service.
Table B-13 describes the subelements of the cache-service-proxy element.
Table B-13 cache-service-proxy Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the fully qualified name of a class that implements the |
|
Optional |
Contains initialization parameters for the |
|
|
< |
Optional |
Specifies whether the cache service proxy is enabled. If disabled, clients are not able to access any proxied caches. Legal values are |
|
< |
Optional |
Specifies whether lock requests from remote clients are permitted on a proxied cache. Legal values are |
|
< |
Optional |
Specifies whether requests from remote clients that update a cache are prohibited on a proxied cache. Legal values are |
Used in: local-scheme, read-write-backing-map-scheme
Cache store schemes define a mechanism for connecting a cache to a back-end data store. The cache store scheme may use any class implementing either the com.tangosol.net.cache.CacheStore or com.tangosol.net.cache.CacheLoader interfaces, where the former offers read-write capabilities, where the latter is read-only. Custom implementations of these interfaces may be produced to connect Coherence to various data stores. See "Cache of a Database" for an example of using a cachestore-scheme.
Table B-14 describes the subelements of the cachestore-scheme element.
Table B-14 cachestore-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
<scheme-name> |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
<scheme-ref> |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance". |
|
Optional |
Specifies the implementation of the cache store. The specified class must implement either of the following interfaces.
|
|
|
Optional |
Configures the cachestore-scheme to use Coherence*Extend as its cache store implementation. |
|
|
Optional |
Specifies the configuration information for a bundling strategy. |
Used in: cache-config
Defines mappings between cache names, or name patterns, and caching-schemes. For instance you may define that caches whose names start with accounts- uses a distributed (distributed-scheme) caching scheme, while caches starting with the name rates- uses a replicated-scheme caching scheme.
Table B-15 describes the subelement you can define within the caching-scheme-mapping element.
Used in: cache-config
The caching-schemes element defines a series of cache scheme elements. Each cache scheme defines a type of cache, for instance a database backed partitioned cache, or a local cache with an LRU eviction policy. Scheme types are bound to actual caches using mappings (see caching-scheme-mapping).
Table B-16 describes the different types of schemes you can define within the caching-schemes element.
Table B-16 caching-schemes Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Defines a cache scheme where storage of cache entries is partitioned across the cluster nodes. |
|
|
Optional |
Defines a replicated cache scheme which uses optimistic rather then pessimistic locking. |
|
|
Optional |
Defines a cache scheme where each cache entry is stored on all cluster nodes. |
|
|
Optional |
Defines a cache scheme where storage of cache entries is partitioned across the cluster nodes with transactional guarantees. |
|
|
Optional |
Defines a cache scheme which provides on-heap cache storage. |
|
|
Optional |
Defines a cache scheme which provides off-heap cache storage, for instance on disk. |
|
|
Optional |
Defines a cache scheme which provides off-heap cache storage, that is size-limited by using time based paging. |
|
|
Optional |
Defines a two tier cache scheme where entries evicted from a size-limited front-tier overflow and are stored in a much larger back-tier cache. |
|
|
Optional |
Defines a cache scheme using a custom cache implementation. Any custom implementation must implement the |
|
|
Optional |
Specifies a scheme that stores data to flash memory. |
|
|
Optional |
Specifies a scheme that stores data to RAM memory. |
|
|
Optional |
Defines a two tier cache scheme which consists of a fast local front-tier cache of a much larger back-tier cache. |
|
|
Optional |
Defines an invocation service which can be used for performing custom operations in parallel across cluster nodes. |
|
|
Optional |
Defines a backing map scheme which provides a cache of a persistent store. |
|
|
Optional |
Defines a cache scheme that enables caches to be accessed from outside a Coherence cluster by using Coherence*Extend. |
|
|
Optional |
Defines an invocation scheme that enables invocations from outside a Coherence cluster by using Coherence*Extend. |
|
|
Optional |
Defines a proxy service scheme that enables remote connections to a cluster using Coherence*Extend. |
Used in: caching-schemes, local-scheme, distributed-scheme, replicated-scheme, optimistic-scheme, near-scheme, front-scheme, overflow-scheme, read-write-backing-map-scheme, cachestore-scheme, listener, eviction-policy, unit-calculator.
Class schemes provide a mechanism for instantiating an arbitrary Java object for use by other schemes. The scheme which contains this element dictates what class or interface(s) must be extended. See "Cache of a Database" for an example of using a class-scheme.
The class-scheme may be configured to either instantiate objects directly by using their class-name, or indirectly by using a class-factory-name and method-name. The class-scheme must be configured with either a class-name or class-factory-name and method-name.
Table B-17 describes the subelements of the class-scheme element.
Table B-17 class-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Contains a fully specified Java class name to instantiate. This class must extend an appropriate implementation class as dictated by the containing scheme and must declare the exact same set of public constructors as the superclass. This element cannot be used with the |
|
< |
Optional |
Specifies a fully specified name of a Java class that is used as a factory for object instantiation. This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Specifies initialization parameters which are accessible by implementations that include a public constructor with a matching signature. |
Used in: external-scheme, paged-external-scheme, async-store-manager.
Used to create and configure custom implementations of a store manager for use in external caches.
Table B-18 describes the subelements of the custom-store-manager element.
Table B-18 custom-store-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
Specifies the implementation of the store manager. The specified class must implement the |
|
Optional |
Specifies initialization parameters, for use in custom store manager implementations. |
Used in: cache-config
The defaults element defines factory wide default settings. This feature enables global configuration of serializers and socket providers used by all services which have not explicitly defined these settings.
Table B-19 describes the subelements of the defaults element.
Table B-19 defaults Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the scope name for this configuration. The scope name is added (as a prefix) to all services generated by a cache factory. The name is used to isolate services when using multiple cache factories; thus, avoiding unintended joining of services with similar names from different configurations. |
|
Optional |
Specifies either: the class configuration information for a <serializer>pof</serializer> |
|
|
Optional |
Specifies either: the configuration for a socket provider, or it references a socket provider configuration that is defined within the <socket-provider>ssl</socket-provider> This setting only specifies the socket provider for Coherence*Extend services. The TCMP socket provider is specified within the <unicast-listener> element in the operational configuration. |
Used in: caching-schemes, near-scheme, overflow-scheme
The distributed-scheme defines caches where the storage for entries is partitioned across cluster nodes. See "Understanding Distributed Caches" for a more detailed description of partitioned caches. See "Partitioned Cache" for examples of various distributed-scheme configurations.
Partitioned caches support cluster wide key-based locking so that data can be modified in a cluster without encountering the classic missing update problem. Note that any operation made without holding an explicit lock is still atomic but there is no guarantee that the value stored in the cache does not change between atomic operations.
The partitioned cache service supports the concept of cluster nodes which do not contribute to the overall storage of the cluster. Nodes which are not storage enabled (see <local-storage> subelement) are considered "cache clients".
The cache entries are evenly segmented into several logical partitions (see <partition-count> subelement), and each storage enabled (see <local-storage> subelement) cluster node running the specified partitioned service (see <service-name> subelement) is responsible for maintain a fair-share of these partitions.
By default the specific set of entries assigned to each partition is transparent to the application. In some cases it may be advantageous to keep certain related entries within the same cluster node. A key-associator (see <key-associator> subelement) may be used to indicate related entries, the partitioned cache service ensures that associated entries reside on the same partition, and thus on the same cluster node. Alternatively, key association may be specified from within the application code by using keys which implement the com.tangosol.net.cache.KeyAssociation interface.
Storage for the cache is specified by using the <backing-map-scheme> subelement. For instance a partitioned cache which uses a local-scheme for its backing map results in cache entries being stored in-memory on the storage-enabled cluster nodes.
For the purposes of failover, a configured number of backups (see <backup-count> subelement) of the cache may be maintained in backup-storage (see <backup-storage> subelement) across the cluster nodes. Each backup is also divided into partitions, and when possible a backup partition does not reside on the same computer as the primary partition. If a cluster node abruptly leaves the cluster, responsibility for its partitions are automatically reassigned to the existing backups, and new backups of those partitions are created (on remote nodes) to maintain the configured backup count.
When a node joins or leaves the cluster, a background redistribution of partitions occurs to ensure that all cluster nodes manage a fair-share of the total number of partitions. The amount of bandwidth consumed by the background transfer of partitions is governed by the transfer-threshold (see <transfer-threshold> subelement).
Table B-20 describes the subelements of the distributed-scheme element.
Table B-20 distributed-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a name for the distributed cache service instance that manages the cache that is created from this distributed scheme. The distributed cache service definition is defined within the |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
Optional |
Specifies either: the class configuration information for a |
|
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies whether or not backup updates should be compressed in delta form or sent whole. A delta update represents the parts of a backup entry that must be changed in order to synchronize it with the primary version of the entry. Deltas are created and applied using a compressor. The default value is the
|
|
< |
Optional |
Specifies the number of daemon threads used by the partitioned cache service. Legal values are positive integers, |
|
|
Optional |
Specifies the priority for the worker threads. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
< |
Optional |
Specifies the lease ownership granularity. Legal values are:
A value of thread means that locks are held by a thread that obtained them and can only be released by that thread. A value of member means that locks are held by a cluster node and any thread running on the cluster node that obtained the lock can release it. The default value is the |
|
< |
Optional |
Specifies whether a cluster node contributes storage to the cluster, that is, maintain partitions. When disabled the node is considered a cache client. Legal values are |
|
< |
Optional |
Specifies the number of distributed cache partitions. Each storage-enabled cluster member that is running the distributed cache service manages a balanced number of partitions. Valid values are positive integers between 1 and 32767 and should be a prime number. A list of primes can be found at |
|
< |
Optional |
Specifies the threshold for the primary buckets distribution in kilobytes. When a new node joins the partitioned cache service or when a member of the service leaves, the remaining nodes perform a task of bucket ownership re-distribution. During this process, the existing data gets re-balanced along with the ownership information. This parameter indicates a preferred message size for data transfer communications. Setting this value lower makes the distribution process take longer, but reduces network bandwidth utilization during this activity. Legal values are integers greater then zero. The default value is the |
|
< |
Optional |
Specifies the number of members of the partitioned cache service that hold the backup data for each unit of storage in the cache. A value of 0 means that for abnormal termination, some portion of the data in the cache is lost. The default value is the |
|
< |
Optional |
Specifies the number of members of the partitioned cache service that holds the backup data for each unit of storage in the cache that does not require write-behind, that is, data that is not vulnerable to being lost even if the entire cluster were shut down. Specifically, if a unit of storage is marked as requiring write-behind, then it is backed up on the number of members specified by the This value should be set to 0 or this setting should not be specified at all. The rationale is that since this data is being backed up to another data store, no in-memory backup is required, other than the data temporarily queued on the write-behind queue to be written. The value of 0 means that when write-behind has occurred, the backup copies of that data is discarded. However, until write-behind occurs, the data is backed up in accordance with the Recommended value is 0 or this element should be omitted. |
|
Optional |
Specifies the type and configuration for the partitioned cache backup storage. |
|
|
Optional |
Specifies a class that is responsible for providing associations between keys and allowing associated keys to reside on the same partition. This implementation must have a zero-parameter public constructor. |
|
|
Optional |
Specifies a class that implements the |
|
|
|
Optional |
Specifies the strategy that is used by a partitioned service to manage partition distribution. The default value is the
|
|
Optional |
Specifies a class that implements the |
|
|
< |
Optional |
Specifies the amount of time in milliseconds that a task can execute before it is considered "hung". Note: a posted task that has not yet started is never considered as hung. This attribute is applied only if the Thread pool is used (the |
|
< |
Optional |
Specifies the timeout value in milliseconds for requests executing on the service worker threads. This attribute applies only if the thread pool is used (the |
|
< |
Optional |
Specifies the maximum amount of time a client waits for a response before abandoning the original request. The request time is measured on the client side as the time elapsed from the moment a request is sent for execution to the corresponding server node(s) and includes the following:
Legal values are positive integers or zero (indicating no default timeout). The default value is the value specified in the |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
|
Optional |
Specifies the configuration information for a class that implements the The |
|
Optional |
Specifies the configuration information for a bundling strategy. |
|
|
Optional |
Specifies what type of cache is used within the cache server to store the entries. Legal schemes are: Note that when using an off-heap backing map it is important that the corresponding < |
|
|
Optional |
Specifies quorum policy settings for the partitioned cache service. |
|
|
< |
Optional |
Specifies an implementation of a |
|
< |
Optional |
The |
|
Optional |
Specifies any number of event interceptors that process events for all caches of a specific distributed service. |
|
|
|
Optional |
Specifies whether the partitioned (distributed) cache service backs up data asynchronously while concurrently responding to the client. Asynchronous backup is often used to increase client performance. However, applications that require strict data integrity must be designed and tested to ensure that data is not at risk. Legal values are |
Used in: caching-schemes, distributed-scheme, replicated-scheme, optimistic-scheme, near-scheme, overflow-scheme, read-write-backing-map-scheme
External schemes define caches which are not JVM heap based, allowing for greater storage capacity. See "Local Caches (accessible from a single JVM)" for examples of various external cache configurations.
This scheme is implemented by:
com.tangosol.net.cache.SerializationMap—for unlimited size caches
com.tangosol.net.cache.SerializationCache—for size limited caches
The implementation type is chosen based on the following rule:
if the <high-units> subelement is specified and not zero then SerializationCache is used;
otherwise SerializationMap is used.
External schemes use a pluggable store manager to store and retrieve binary key value pairs. Supported store managers include:
a wrapper providing asynchronous write capabilities for of other store manager implementations
allows definition of custom implementations of store managers
uses Berkeley Database JE to implement an on disk cache
uses NIO to implement memory-mapped file based cache
uses NIO to implement an off JVM heap, in-memory cache
Note:
The NIO memory manager implementation is deprecated. Current implementation should use a journal binary store instead. See "Using the Elastic Data Feature to Store Data".The cache may be configured as size-limited, which means that when it reaches its maximum allowable size (that is, the <high-units> subelement) it prunes itself.
Note:
Eviction against disk-based caches can be expensive, consider using a paged-external-scheme for such cases.External schemes support automatic expiration of entries based on the age of the value, as configured by the <expiry-delay> subelement.
Persistence (long-term storage)
External caches are generally used for temporary storage of large data sets, for example as the back-tier of an overflow-scheme. The Berkly database JE implementation does however support persistence for non-clustered caches, see the <store-name> subelement of bdb-store-manager. Clustered persistence should be configured by using a read-write-backing-map-scheme on a distributed-scheme.
Table B-21 describes the subelements of the external-scheme element.
Table B-21 external-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information |
|
< |
Optional |
Specifies a custom implementation of the external cache. Any custom implementation must extend either of the following classes:
and declare the exact same set of public constructors as the superclass. |
|
Optional |
Specifies initialization parameters, for use in custom external cache implementations. |
|
|
Optional |
Configures the external cache to use an asynchronous storage manager wrapper for any other storage manager. See "Pluggable Storage Manager" |
|
|
Optional |
Configures the external cache to use Berkeley Database JE on disk databases for cache storage. |
|
|
Optional |
Configures the external cache to use a custom storage manager implementation. |
|
|
Optional |
Configures the external cache to use a memory-mapped file for cache storage. |
|
|
Optional |
Configures the external cache to use an off JVM heap, memory region for cache storage. |
|
|
< |
Optional |
Specifies the size limit of the cache. The value represents the maximum number of units that can be placed in the cache before pruning occurs. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the Note: The value is limited to approximately 2GB by default. To specify higher values, use the |
|
< |
Optional |
Specifies the type of unit calculator to use. A unit calculator is used to determine the cost (in "units") of a given object. This element is used only if the
|
|
< |
Optional |
Specifies the factor by which the Note: This element was introduced only to avoid changing the type of the Valid values are positive integers. The default value is |
|
< |
Optional |
Specifies the amount of time since the last update that entries are kept by the cache before being expired. Entries that have expired are not be accessible and are evicted the next time a client accesses the cache. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. A value of zero implies no expiry. The default value is Note: The expiry delay parameter ( |
|
< |
Optional |
Specifies an implementation of a |
Used in: back-scheme, backing-map-scheme, caching-schemes, internal-cache-scheme
The flashjournal-scheme element contains the configuration information for a scheme that stores data to external block-based file stores (flash). A flash journal resource manager controls flash journal behavior. See "flashjournal-manager" for additional details on configuring flash journal behavior.
This scheme uses the com.tangosol.net.cache.CompactSerializationCache class as the backing map implementation and the com.tangosol.io.journal.JournalBinaryStore to store and retrieve binary key value pairs to a journal.
Table B-22 describes the subelements of the flashjournal-scheme element.
Table B-22 flashjournal-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the simple serialization map cache. Any custom implementation must extend the |
|
Optional |
Specifies the initialization parameters for a custom serialization map cache. |
|
|
< |
Optional |
Specifies the type of eviction policy to use. Legal values are:
|
|
< |
Optional |
Specifies the size limit of the cache. The value represents the maximum number of units that can be placed in the cache before pruning occurs. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the Note: The value is limited to approximately 2GB by default. To specify higher values, use the |
|
< |
Optional |
Specifies the lowest number of units that a cache is pruned down to when pruning takes place. A pruning does not necessarily result in a cache containing this number of units; however, a pruning never results in a cache containing less than this number of units. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the |
|
< |
Optional |
Specifies the type of unit calculator to use. A unit calculator is used to determine the cost (in "units") of a given object. This element is used only if the
|
|
< |
Optional |
Specifies the factor by which the Note: This element was introduced only to avoid changing the type of the Valid values are positive integers. The default value is |
|
< |
Optional |
Specifies the amount of time since the last update that entries are kept by the cache before being expired. Entries that have expired are not accessible and are evicted the next time a client accesses the cache. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. A value of zero implies no expiry. The default value is Note: The expiry delay parameter ( |
|
< |
Optional |
Specifies an implementation of a |
Used in: near-scheme, overflow-scheme
Table B-23 describes the subelements of the front-scheme element.
Table B-23 front-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Local cache schemes define in-memory "local" caches. Local caches are generally nested within other cache schemes, for instance as the front-tier of a near scheme. |
|
|
Optional |
Class schemes provide a mechanism for instantiating an arbitrary Java object for use by other schemes. The scheme which contains this element dictates what class or interface(s) must be extended. |
Used in acceptor-config
The http-acceptor element specifies an acceptor for connections from remote REST clients over HTTP.
Table B-24 describes the subelements of the http-acceptor element.
Table B-24 http-acceptor subelements
| Elements | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies an HTTP server class that implements the |
|
Optional |
Contains class initialization parameters for the HTTP server class. |
|
|
Optional |
Specifies the configuration for a socket and channel factory. |
|
|
Required |
Specifies the local address (IP, or DNS name, and port) on which the HTTP server socket is bound. |
|
|
Optional |
Specifies a Jersey resource configuration class that is used by the HTTP acceptor to load resource and provider classes. |
|
|
|
Optional |
Specifies the authentication mechanism for the HTTP server. A client must have authenticated using the configured mechanism as a prerequisite to gaining access to any resources exposed by the server. Legal values are:
|
Used in: ssl.
The <identity-manager> element contains the configuration information for initializing a javax.net.ssl.KeyManager instance.
The identity manager is responsible for managing the key material which is used to authenticate the local connection to its peer. If no key material is available, the connection cannot present authentication credentials.
Table B-25 describes the elements you can define within the identity-manager element.
Table B-25 identity-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the algorithm used by the identity manager. The default value is |
|
|
Optional |
Specifies the configuration for a security provider instance. |
|
Optional |
Specifies the configuration for a key store implementation. |
|
|
|
Required |
Specifies the private key password. |
Used in: acceptor-config, initiator-config.
The <incoming-message-handler> element contains the configuration information that is used to regulate client-to-cluster connection resource usage. Connection initiators and acceptors use this information to proactively detect and release connections that use excessive resources.
Table B-25 describes the elements you can define within the incoming-message-handler element.
Table B-26 incoming-message-handler Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the size limit of messages being sent over Coherence*Extend connections. The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of kilo is assumed. Legal values are positive integers between 0 and |
Used in: remote-cache-scheme, remote-invocation-scheme.
The initiator-config element specifies the configuration information for a TCP/IP connection initiator. A connection initiator allows a Coherence*Extend client to connect to a cluster (by using a connection acceptor) and use the clustered services offered by the cluster without having to first join the cluster.
Table B-27 describes the subelements of the initiator-config element.
Table B-27 initiator-config Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the configuration information for a connection initiator that connects to the cluster over TCP/IP. |
|
|
Optional |
Specifies the configuration information that is used to regulate client-to-cluster connection resource usage. |
|
|
Optional |
Specifies the configuration information used by the connection initiator to detect dropped client-to-cluster connections. |
|
|
< |
Optional |
Contains the list of filter names to be used by this connection acceptor. For example, specifying
<use-filters>
<filter-name>gzip</filter-name>
</use-filters>
|
|
Optional |
Specifies either: the class configuration information for a |
|
|
< |
Optional |
Specifies the maximum amount of time to wait while establishing a connection with a connection acceptor.The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. The default value is an infinite timeout. |
Used in: init-params.
Table B-28 describes the subelements of the init-param element.
Table B-28 init-param Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the name of the initialization parameter. For example: <init-param> <param-name>sTableName</param-name> <param-value>EmployeeTable</param-value> </init-param> The |
|
< |
Optional |
Specifies the Java type of the initialization parameter.The following standard types are supported:
For example: <init-param> <param-type>java.lang.String</param-type> <param-value>EmployeeTable</param-value> </init-param> The |
|
< |
Required |
Specifies the value of the initialization parameter. The value is in the format specific to the Java type of the parameter. |
|
|
Optional |
Specifies a description for the initialization parameter. |
Used in: class-scheme, cache-mapping.
Defines a series of initialization parameters as name-value pairs. See "Partitioned Cache of a Database" for an example of using init-params.
Table B-29 describes the subelements of the init-params element.
Used in: interceptor, serializer, service-failure-policy, load-balancer, and partition-assignment-strategy
The <instance> element contains the configuration of an implementation class or class factory that is used to plug in custom functionality.
Table B-30 describes the subelements of the instance element.
Table B-30 instance Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the fully qualified name of an implementation class. This element cannot be used with the |
|
|
Optional |
Specifies the fully qualified name of a factory class for creating implementation class instances. This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: interceptors
The interceptor element defines the configuration associated with an event interceptor that is responsible for processing live events. Event interceptors extend the com.tangosol.net.events.AbstractConfigurableEventInterceptor class. The base class provides the ability to restrict an event interceptor to a specific cache or service. The base class also provides support for the @Interceptor annotation, which allows an implementation to register for a subset of events based on event types and to configure an event interceptor identifier and the ordering of event interceptors. Specifying an interceptor's identifier and ordering within the interceptor element overrides the settings in the base class.
Table B-31 describes the subelements of the interceptor element.
Table B-31 interceptor Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies a unique identifier for the interceptor. |
|
|
Optional |
Specifies whether the interceptor is the first interceptor in a chain of interceptors. The legal values are |
|
|
Required |
Specifies the interceptor class to instantiate. The interceptor class must extend the |
Used in: cache-mapping and distributed-scheme
Table B-32 describes the subelements of the interceptors element.
Used in: caching-schemes.
Defines an Invocation Service. The invocation service may be used to perform custom operations in parallel on any number of cluster nodes. See the com.tangosol.net.InvocationService API for additional details.
Table B-33 describes the subelements of the invocation-scheme element.
Table B-33 invocation-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service which manages invocations from this scheme. |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
Optional |
Specifies either: the class configuration information for a |
|
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies the number of daemon threads used by the invocation service. Legal values are positive integers, |
|
|
Optional |
Specifies the priority for the worker threads. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
|
Optional |
Specifies the amount of time in milliseconds that a task can execute before it is considered "hung". Note: a posted task that has not yet started is never considered as hung. This attribute is applied only if the Thread pool is used (the |
|
|
Optional |
Specifies the default timeout value for tasks that can time out (for example, implement the |
|
|
Optional |
Specifies the maximum amount of time a client waits for a response before abandoning the original request. The request time is measured on the client side as the time elapsed from the moment a request is sent for execution to the corresponding server node(s) and includes the following:
Legal values are positive integers or zero (indicating no default timeout). The default value is the |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
|
Optional |
Specifies the configuration information for a class that implements the The |
|
< |
Optional |
The |
Used in: proxy-config
The invocation-service-proxy element contains the configuration information for an invocation service proxy managed by a proxy service.
Table B-34 describes the subelements of the invocation-service-proxy element.
Table B-34 invocation-service-proxy Subelement
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the fully qualified name of a class that implements the |
|
Optional |
Contains initialization parameters for the |
|
|
< |
Optional |
Specifies whether the invocation service proxy is enabled. If disabled, clients are not able to execute |
Used in: distributed-scheme
Specifies an implementation of a com.tangosol.net.partition.KeyAssociator which is used to determine associations between keys, allowing related keys to reside on the same partition.
Alternatively the cache's keys may manage the association by implementing the com.tangosol.net.cache.KeyAssociation interface.
Table B-35 describes the subelements of the key-associator element.
Table B-35 key-associator Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
The name of a class that implements the |
|
|
Optional |
Specifies the fully qualified name of a factory class for creating implementation class instances. This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: distributed-scheme
Specifies an implementation of a com.tangosol.net.partition.KeyPartitioningStrategy which is used to determine the partition in which a key resides.
Table B-36 describes the subelements of the key-partitioning element.
Table B-36 key-partitioning Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
The name of a class that implements the |
|
|
Optional |
Specifies the fully qualified name of a factory class for creating implementation class instances. This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: identity-manager, trust-manager.
The key-store element specifies the configuration for a key store implementation to use when implementing SSL. The key store implementation is an instance of the java.security.KeyStore class.
Table B-37 describes the elements you can define within the key-store element.
Table B-37 key-store Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Required |
Specifies the Uniform Resource Locator (URL) to a key store. |
|
|
Optional |
Specifies the password for the key store. |
|
|
Optional |
Specifies the type of a |
Used in: local-scheme, external-scheme, paged-external-scheme, distributed-scheme, replicated-scheme, optimistic-scheme, near-scheme, overflow-scheme, read-write-backing-map-scheme
The Listener element specifies an implementation of a com.tangosol.util.MapListener which is notified of events occurring on a cache.
Table B-38 describes the subelements of the listener element.
Table B-38 listener Subelement
| Element | Required/ Optional |
Description |
|---|---|---|
|
Required |
Specifies the full class name of the listener implementation to use. The specified class must implement the |
Used in: http-acceptor, tcp-acceptor, tcp-initiator
The local-address element specifies the local address (IP, or DNS name, and port) to which a socket is bound.
A local address for the <tcp-acceptor> element specifies a TCP/IP server socket that is used by the proxy service to accept connections from Coherence*Extend clients. A local address for the <http-acceptor> element specifies a HTTP server socket that is used to accept connections from REST clients. The following example binds a server socket to 192.168.0.2:9099.
<local-address> <address>192.168.0.2</address> <port>9099</port> </local-address>
A local address for the <tcp-initiator> element specifies a TCP/IP client socket that is used by remote services to connect to a proxy service on the cluster. The following example binds the client socket to 192.168.0.1 on port 9099:
<local-address> <address>192.168.0.1</address> <port>9099</port> </local-address>
Note:
A socket addresses for the TCP/IP acceptor can also be defined using anaddress-provider element. For details, see "address-provider".Table B-65 describes the subelements of the local-address element.
Table B-39 local-address Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the address (IP or DNS name) on which a socket listens and publishes. If the address is a bind address, then the address may also be entered using CIDR notation as a subnet and mask (for example, |
|
< |
Optional |
Specifies the port on which a TCP/IP socket listens and publishes. The legal values are from 1 to 65535. |
Used in: caching-schemes, distributed-scheme, replicated-scheme, optimistic-scheme, near-scheme, front-scheme, overflow-scheme, read-write-backing-map-scheme, backing-map-scheme
Local cache schemes define in-memory "local" caches. Local caches are generally nested within other cache schemes, for instance as the front-tier of a near-scheme. See "Near Cache" for examples of various local cache configurations.
Local caches are implemented by the com.tangosol.net.cache.LocalCache class.
A local cache may be backed by an external cache store (see "cachestore-scheme"). Cache misses are read-through to the back end store to retrieve the data. If a writable store is provided, cache writes are also propagate to the cache store. For optimizing read/write access against a cache store, see the "read-write-backing-map-scheme".
The cache may be configured as size-limited, which means that when it reaches its maximum allowable size (see the <high-units> subelement) it prunes itself back to a specified smaller size (see the <low-units> subelement), choosing which entries to evict according to its eviction-policy (see the <eviction-policy> subelement). The entries and size limitations are measured in terms of units as calculated by the scheme's unit calculator (see the <unit-calculator> subelement).
The local cache supports automatic expiration of entries based on the age of the value (see the <expiry-delay> subelement).
Table B-40 describes the subelements of the local-scheme element.
Table B-40 local-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the local cache. Any custom implementation must extend the |
|
< |
Optional |
Specifies the name of the service which manages caches created from this scheme. Services are configured from within the |
|
Optional |
Specifies initialization parameters, for use in custom local cache implementations. |
|
|
< |
Optional |
Specifies the type of eviction policy to use.Legal values are:
|
|
< |
Optional |
Specifies the size limit of the cache. The value represents the maximum number of units that can be placed in the cache before pruning occurs. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the Note: The value is limited to approximately 2GB by default. To specify higher values, use the |
|
< |
Optional |
Specifies the lowest number of units that a cache is pruned down to when pruning takes place. A pruning does not necessarily result in a cache containing this number of units; however, a pruning never results in a cache containing less than this number of units. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the |
|
< |
Optional |
Specifies the type of unit calculator to use. A unit calculator is used to determine the cost (in "units") of a given object. This element is used only if the
|
|
< |
Optional |
Specifies the factor by which the Note: This element was introduced only to avoid changing the type of the Valid values are positive integers. The default value is |
|
< |
Optional |
Specifies the amount of time since the last update that entries are kept by the cache before being expired. Entries that have expired are not accessible and are evicted the next time a client accesses the cache. When using a cache store, any attempt to read an expired entry results in a reloading of the entry from the configured cache store (see < The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. A value of zero implies no expiry. The default value is Note: The expiry delay parameter ( |
|
Optional |
Specifies the store which is being cached. If unspecified the cached data only resides in memory, and only reflects operations performed on the cache itself. |
|
|
|
Optional |
Specifies whether a cache pre-loads data from its |
|
< |
Optional |
Specifies an implementation of a |
Used in: acceptor-config
The memcached-acceptor element contains the configuration information for an acceptor that accepts connections from remote memcached clients over TCP/IP. The acceptor allows memcached clients to use a Coherence cache over the memcached binary protocol.
Table B-41 describes the subelements of the memcached-acceptor element.
Table B-41 memcached-acceptor Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Required |
Specifies the cache that is used by memcached clients that connect to the memcached acceptor. The cache name is resolved to an actual cache scheme using cache mappings. See "cache-mapping" for details. The cache name must resolve to a partitioned cache scheme. |
|
|
Optional |
Specifies wether the memcached acceptor can by-pass the configured cache service serializer while storing the values in the cache. This is only required when sharing data between Coherence*Extend and memcached clients. The assumption is that memcached clients are using a Coherence serializer, like the POF serializer, to convert the objects into |
|
|
Optional |
Specifies the authentication mechanism for the memcached acceptor. A client must authenticate using the configured mechanism to gain access to any resources exposed by the server. Legal values are |
|
Optional |
Specifies the configuration for a socket and channel factory. |
|
|
Required |
Specifies either the local address (IP, or DNS name, and port) on which the TCP/IP server socket is bound or an implementation of the |
Used in: tcp-initiator
The name-service-addresses element contains the address (IP, or DNS name, and port) of one or more name service TCP/IP acceptors. A TCP/IP initiator uses this information to establish a connection with a remote cluster. The TCP/IP initiator attempts to connect to the addresses in a random order until either the list is exhausted or a connection is established. See Developing Remote Clients for Oracle Coherence for additional details and example configurations.
Table B-42 describes the subelements of the name-service-addresses element.
Table B-42 name-service-addresses Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the address (IP, or DNS name, and port) on which a name service TCP/IP acceptor is listening. Multiple |
|
|
Optional |
Specifies the address (IP, or DNS name, and port) on which a name service TCP/IP acceptor is listening or the configuration for a A |
Used in: caching-schemes.
The near-scheme defines a two-tier cache consisting of a front-tier which caches a subset of a back-tier cache. The front-tier is generally a fast, size limited cache, while the back-tier is slower, but much higher capacity cache. A typical deployment might use a local cache for the front-tier, and a distributed cache for the back-tier. The result is that a portion of a large partitioned cache is cached locally in-memory allowing for very fast read access. See "Understanding Near Caches" for a more detailed description of near caches, and "Near Cache" for an example of near cache configurations.
The near scheme is implemented by the com.tangosol.net.cache.NearCache class.
The <invalidation-strategy> subelement defines a strategy that is used to keep the front tier of the near cache synchronized with the back tier. Depending on that strategy, a near cache is configured to listen to certain events occurring on the back tier and automatically update (or invalidate) the front portion of the near cache.
Table B-43 describes the subelements of the near-scheme element.
Table B-43 near-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the near cache. Any custom implementation must extend the |
|
Optional |
Specifies initialization parameters for custom near cache implementations. |
|
|
Required |
Specifies the cache to use as the front-tier cache. |
|
|
Required |
Specifies the cache to use as the front-tier cache. |
|
|
< |
Optional |
Specifies the strategy used keep the front-tier in-sync with the back-tier. Please see
|
|
< |
Optional |
Specifies an implementation of a |
|
< |
Optional |
The autostart element is intended to be used by cache servers (that is, |
Used in: external-scheme, paged-external-scheme, async-store-manager.
This store manager is implemented by the com.tangosol.io.nio.MappedStoreManager class. The BinaryStore objects created by this class are instances of the com.tangosol.io.nio.BinaryMapStore.
Table B-44 describes the subelements of the nio-file-manager element.
Table B-44 nio-file-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies a custom implementation of the local cache. Any custom implementation must extend the |
|
Optional |
Specifies initialization parameters, for use in custom nio-file-manager implementations. |
|
|
< |
Optional |
Specifies the initial buffer size in megabytes.The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
|
< |
Optional |
Specifies the maximum buffer size in bytes.The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
|
< |
Optional |
Specifies the path name for the root directory that the manager uses to store files in. If not specified or specifies a non-existent directory, a temporary file in the default location is used. |
Used in: external-scheme, paged-external-scheme, async-store-manager.
Note:
The NIO memory manager implementation is deprecated. Current implementation should use a journal binary store instead. See "Using the Elastic Data Feature to Store Data".Configures a store-manager which uses an off JVM heap, memory region for storage, which means that it does not affect the Java heap size and the related JVM garbage-collection performance that can be responsible for application pauses. See "NIO In-memory Cache" for an example of an NIO cache configuration.
Note:
JVMs require the use of a command line parameter if the total NIO buffers is greater than 64MB. For example:-XX:MaxDirectMemorySize=512MImplemented by the com.tangosol.io.nio.DirectStoreManager class. The BinaryStore objects created by this class are instances of the com.tangosol.io.nio.BinaryMapStore.
Table B-45 describes the subelements of the nio-memory-manager element.
Table B-45 nio-memory-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies a custom implementation of the local cache. Any custom implementation must extend the |
|
Optional |
Specifies initialization parameters, for use in custom |
|
|
< |
Optional |
Specifies the initial buffer size in bytes. The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
|
< |
Optional |
Specifies the maximum buffer size in bytes. The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of mega is assumed. Legal values are positive integers between 1 and |
Used in: cachestore-scheme, distributed-scheme, remote-cache-scheme.
The operation-bundling element specifies the configuration information for a particular bundling strategy.
Bundling is a process of coalescing multiple individual operations into "bundles". It could be beneficial when
there is a continuous stream of operations on multiple threads in parallel;
individual operations have relatively high latency (network or database-related); and
there are functionally analogous "bulk" operations that take a collection of arguments instead of a single one without causing the latency to grow linearly (as a function of the collection size).
Note:
As with any bundling algorithm, there is a natural trade-off between the resource utilization and average request latency. Depending on a particular application usage pattern, enabling this feature may either help or hurt the overall application performance.
Operation bundling affects cache store operations. If operation bundling is configured, the CacheStore.storeAll() method is always called even if there is only one ripe entry.
See com.tangosol.net.cache.AbstractBundler for additional implementation details.
Table B-46 describes the subelement for the operation-bundling element.
Used in: caching-schemes, near-scheme, overflow-scheme
The optimistic scheme defines a cache which fully replicates all of its data to all cluster nodes that run the service (see <service-name> subelement). See "Understanding Optimistic Caches" for a more detailed description of optimistic caches.
Unlike the replicated-scheme and distributed-scheme caches, optimistic caches do not support concurrency control (locking). Individual operations against entries are atomic but there is no guarantee that the value stored in the cache does not change between atomic operations. The lack of concurrency control allows optimistic caches to support very fast write operations.
Storage for the cache is specified by using the <backing-map-scheme> subelement). For instance, an optimistic cache which uses a local-scheme for its backing map results in cache entries being stored in-memory.
Table B-47 describes the subelements of the optimistic-scheme element.
Table B-47 optimistic-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
|
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
|
Optional |
Specifies the name of the service which manages caches created from this scheme. Services are configured from within the |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
Optional |
Specifies either: the class configuration information for a |
|
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies the maximum amount of time a client waits for a response before abandoning the original request. The request time is measured on the client side as the time elapsed from the moment a request is sent for execution to the corresponding server node(s) and includes the following:
Legal values are positive integers or zero (indicating no default timeout). The default value is the value specified in the |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
|
Optional |
Specifies the configuration information for a class that implements the The |
|
Optional |
Specifies what type of cache is used within the cache server to store the entries. Legal values are: To ensure cache coherence, the backing-map of an optimistic cache must not use a read-through pattern to load cache entries. Either use a cache-aside pattern from outside the cache service, or switch to the |
|
|
|
Optional |
Specifies an implementation of a |
|
< |
Optional |
The |
Used in: acceptor-config, initiator-config.
The outgoing-message-handler specifies the configuration information used to detect dropped client-to-cluster connections. For connection initiators and acceptors that use connectionless protocols, this information is necessary to detect and release resources allocated to dropped connections. Connection-oriented initiators and acceptors can also use this information as an additional mechanism to detect dropped connections.
Table B-48 describes the subelements of the outgoing-message-handler element.
Table B-48 outgoing-message-handler Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the interval between ping requests. A ping request is used to ensure the integrity of a connection. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. A value of zero disables ping requests. The default value is zero. |
|
< |
Optional |
Specifies the maximum amount of time to wait for a response to the heartbeat ping request before closing the underlying connection. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
< |
Optional |
Specifies the size limit of messages being sent over Coherence*Extend connections. The value of this element must be in the following format: (\d)+[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of kilo is assumed. Legal values are positive integers between 0 and |
|
< |
Optional |
Specifies the maximum amount of time a client waits for a response message before abandoning the request. The connection is not closed until the Note: This element is not used by a proxy service acceptor, because proxies never send requests to extend clients. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. The default value is an infinite timeout ( |
Used in: caching-schemes, distributed-scheme, replicated-scheme, optimistic-scheme, read-write-backing-map-scheme
The overflow-scheme defines a two-tier cache consisting of a fast, size limited front-tier, and slower but much higher capacity back-tier cache. When the size limited front fills up, evicted entries are transparently moved to the back. In the event of a cache miss, entries may move from the back to the front. A typical deployment might use a local-scheme for the front-tier, and a external-scheme for the back-tier, allowing for fast local caches with capacities larger than the JVM heap allows. In such a deployment, the local-scheme element's high-units and eviction-policy controls the transfer (eviction) of entries from the front to back caches.
Note:
Relying on overflow for normal cache storage is not recommended. It should only be used to help avoid eviction-related data loss in the case where the storage requirements temporarily exceed the configured capacity. In general, the overflow's on-disk storage should remain empty.Implemented by either com.tangosol.net.cache.OverflowMap or com.tangosol.net.cache.SimpleOverflowMap, see expiry-enabled for details.
Overflow supports automatic expiration of entries based on the age of the value, as configured by the <expiry-delay> subelement.
Table B-49 describes the subelements of the overflow-scheme element.
Table B-49 overflow-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the overflow cache. Any custom implementation must extend either the |
|
Optional |
Specifies initialization parameters, for use in custom overflow cache implementations. |
|
|
Required |
Specifies the cache to use as the front-tier cache. |
|
|
Required |
Specifies the cache-scheme to use in creating the back-tier cache. |
|
|
< |
Optional |
Specifies a cache-scheme for maintaining information on cache misses. For caches which are not expiry-enabled (see |
|
< |
Optional |
Turns on support for automatically-expiring data, as provided by the |
|
< |
Optional |
Specifies the amount of time since the last update that entries are kept by the cache before being expired. Entries that have expired are not be accessible and are evicted the next time a client accesses the cache. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. A value of zero implies no expiry. The default value is Note: The expiry delay parameter ( |
|
< |
Optional |
The |
|
< |
Optional |
Specifies an implementation of a |
Used in: caching-schemes, distributed-scheme, replicated-scheme, optimistic-scheme, near-scheme, overflow-scheme, read-write-backing-map-scheme
As with external-scheme, paged-external-schemes define caches which are not JVM heap based, allowing for greater storage capacity. The paged-external scheme optimizes LRU eviction by using a paging approach. See Chapter 16, "Serialization Paged Cache," for a detailed description of the paged cache functionality.
This scheme is implemented by the com.tangosol.net.cache.SerializationPagedCache class.
Cache entries are maintained over a series of pages, where each page is a separate com.tangosol.io.BinaryStore, obtained from the configured storage manager (see "Pluggable Storage Manager"). When a page is created it is considered to be the current page and all write operations are performed against this page. On a configured interval (see <page-duration> subelement), the current page is closed and a new current page is created. Read operations for a given key are performed against the last page in which the key was stored. When the number of pages exceeds a configured maximum (see <page-limit> subelement), the oldest page is destroyed and those items which were not updated since the page was closed are evicted.
For example, configuring a cache with a duration of ten minutes per page, and a maximum of six pages, results in entries being cached for at most an hour. Paging improves performance by avoiding individual delete operations against the storage manager as cache entries are removed or evicted. Instead, the cache simply releases its references to those entries and relies on the eventual destruction of an entire page to free the associated storage of all page entries in a single operation.
External schemes use a pluggable store manager to create and destroy pages, and to access entries within those pages. Supported store-managers include:
async-store-manager—a wrapper providing asynchronous write capabilities for of other store-manager implementations
custom-store-manager—allows definition of custom implementations of store-managers
bdb-store-manager—uses Berkeley Database JE to implement an on disk cache
nio-file-manager—uses NIO to implement memory-mapped file based cache
nio-memory-manager—uses NIO to implement an off JVM heap, in-memory cache
Note:
The NIO memory manager implementation is deprecated. Current implementation should use a journal binary store instead. See "Using the Elastic Data Feature to Store Data".Persistence (long-term storage)
Paged external caches are used for temporary storage of large data sets, for example as the back-tier of an overflow-scheme. These caches are not used for long-term storage (persistence) and do not survive beyond the life of the JVM. Clustered persistence should be configured by using a read-write-backing-map-scheme on a distributed-scheme. If a non-clustered persistent cache is what is needed, refer to "Persistence (long-term storage)".
Table B-50 describes the subelements of the paged-external-scheme element.
Table B-50 paged-external-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the external paged cache. Any custom implementation must extend the com.tangosol.net.cache.SerializationPagedCache class and declare the exact same set of public constructors. |
|
Optional |
Specifies initialization parameters, for use in custom external paged cache implementations. |
|
|
Optional |
Configures the paged external cache to use an asynchronous storage manager wrapper for any other storage manager. See "Pluggable Storage Manager" for more information. |
|
|
Optional |
Configures the paged external cache to use Berkeley Database JE on disk databases for cache storage. |
|
|
Optional |
Configures the paged external cache to use a custom storage manager implementation. |
|
|
Optional |
Configures the paged external cache to use a memory-mapped file for cache storage. |
|
|
Optional |
Configures the paged external cache to use an off JVM heap, memory region for cache storage. |
|
|
< |
Optional |
Specifies the maximum number of pages that the cache manages before older pages are destroyed. Legal values are zero or positive integers between 2 and 3600. The default value is zero. |
|
< |
Optional |
Specifies the length of time, in seconds, that a page in the cache is current. After the duration is exceeded, the page is closed and a new current page is created. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. Legal values are zero or values between 5 and 604800 seconds (one week). The default value is zero. |
|
<listener> |
Optional |
Specifies an implementation of a |
Used in: distributed-scheme
Specifies an implementation of a com.tangosol.net.partition.PartitionListener interface, which allows receiving partition distribution events.
Table B-51 describes the subelements of the partition-listener element.
Table B-51 partition-listener Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
The name of a class that implements the |
|
|
Optional |
Specifies the fully qualified name of a factory class for creating implementation class instances. This element cannot be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: distributed-scheme
The partitioned-quorum-policy-scheme element contains quorum policy settings for the partitioned cache service.
Table B-52 describes the subelements of the partitioned-quorum-policy-scheme element.
Table B-52 partitioned-quorum-policy-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
|
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
|
Optional |
Specifies the minimum number of ownership-enabled members of a partitioned service that must be present to perform partition distribution. The value must be a nonnegative integer. |
|
|
Optional |
Specifies the minimum number of ownership-enabled members of a partitioned service that must be present to restore lost primary partitions from backup. The value must be a nonnegative integer. |
|
|
Optional |
specifies the minimum number of storage members of a cache service that must be present to process "read" requests. A "read" request is any request that does not mutate the state or contents of a cache. The value must be a nonnegative integer. |
|
|
Optional |
specifies the minimum number of storage members of a cache service that must be present to process "write" requests. A "write" request is any request that may mutate the state or contents of a cache. The value must be a nonnegative integer. |
|
|
Optional |
Specifies a class that provides custom quorum policies. This element cannot be used with the default quorum elements or the The class must implement the |
|
|
Optional |
Specifies a factory class for creating custom action policy instances. This element cannot be used with the default quorum elements or the This element is used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: ssl, identity-manager, trust-manager.
The provider element contains the configuration information for a security provider that extends the java.security.Provider class.
Table B-53 describes the subelements you can define within the provider element.
Table B-53 provider Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the name of a security provider that extends the The class name can be entered using either this element or by using the |
|
|
Optional |
Specifies the name of a security provider that extends the This element cannot be used with the |
|
|
Optional |
Specifies a factory class for creating This element cannot be used with the This element can be used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the provider implementation. This element cannot be used with the |
Used in: proxy-scheme.
The proxy-config element specifies the configuration information for the clustered service proxies managed by a proxy service. A service proxy is an intermediary between a remote client (connected to the cluster by using a connection acceptor) and a clustered service used by the remote client.
Table B-54 describes the subelements of the proxy-config element.
Used in: caching-schemes.
The proxy-scheme element contains the configuration information for a clustered service that allows Coherence*Extend clients to connect to the cluster and use clustered services without having to join the cluster.
Table B-55 describes the subelements of the proxy-scheme element.
Table B-55 proxy-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service. |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the value specified in the |
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies the number of daemon threads for use by the proxy service. Specifying a value creates a thread pool that contains the exact number of threads. Proxy service threads perform operations on behalf of the calling application. Therefore, when explicitly setting the number of threads, set the value to as many threads as there are concurrent operations. Note: The default proxy service configuration uses a dynamic thread pool that automatically adjusts the number of threads based on proxy service load. Dynamic thread pooling is generally recommended. Do not use this element if you want to use dynamic thread pooling. To adjust dynamic thread pool thresholds, use the To disable a thread pool and force all tasks to be performed on the proxy service thread, do not use this element and set the |
|
|
Optional |
Specifies the maximum number of daemon threads that are allowed in a dynamic thread pool. This element is only valid if the |
|
|
Optional |
Specifies the minimum number of daemon threads that are allowed (and initially created) in a dynamic thread pool. This element is only valid if the |
|
|
Optional |
Specifies the priority for the worker threads. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the value specified in the |
|
< |
Optional |
Specifies the amount of time in milliseconds that a task can execute before it is considered hung. Note that a posted task that has not yet started is never considered as hung. This attribute is applied only if the thread pool is used (the |
|
< |
Optional |
Specifies the timeout value in milliseconds for requests executing on the service worker threads. This attribute is applied only if the thread pool is used (the |
|
< |
Optional |
Specifies the maximum amount of time a proxy waits for requests that are sent to other proxies of the same name. This element should not be used because requests are never sent between proxies. |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
|
Optional |
Specifies the configuration information for a class that implements the The |
|
Required |
Contains the configuration of the connection acceptor used by the service to accept connections from Coherence*Extend clients and to allow them to use the services offered by the cluster without having to join the cluster. |
|
|
Optional |
Contains the configuration of the clustered service proxies managed by this service. |
|
|
|
Optional |
Specifies a pluggable strategy used by the proxy service to distribute client connections across the set of clustered proxy service members. Legal values are:
|
|
Optional |
Specifies quorum policy settings for the Proxy service. |
|
|
< |
Optional |
The |
Used in: proxy-scheme
The proxy-quorum-policy-scheme element contains quorum policy settings for the Proxy service.
Table B-55 describes the subelements of the proxy-quorum-policy-scheme element.
Table B-56 proxy-quorum-policy-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
|
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
|
Optional |
specifies the minimum number of members of a proxy service that must be present to allow client connections. The value must be a nonnegative integer. |
|
|
Optional |
Specifies a class that provides custom quorum policies. This element cannot be used with the The class must implement the |
|
|
Optional |
Specifies a factory class for creating custom action policy instances. This element cannot be used with the This element is used with the |
|
< |
Optional |
Specifies the name of a static factory method on the factory class which performs object instantiation. |
|
Optional |
Contains class initialization parameters for the implementation class. |
Used in: back-scheme, backing-map-scheme, caching-schemes, internal-cache-scheme
The ramjournal-scheme element contains the configuration information for a scheme that stores data to buffers (journal files) in-memory. A RAM journal resource manager controls RAM journal behavior. See "ramjournal-manager" for additional details on configuring RAM journal behavior.
This scheme uses the com.tangosol.net.cache.CompactSerializationClass class as the backing map implementation and the com.tangosol.io.journal.JournalBinaryStore to store and retrieve binary key value pairs to a journal.
Table B-57 describes the subelements of the ramjournal-scheme element.
Table B-57 ramjournal-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the simple serialization map cache. Any custom implementation must extend the |
|
Optional |
Specifies the initialization parameters for a custom serialization map cache. |
|
|
< |
Optional |
Specifies the type of eviction policy to use. Legal values are:
|
|
< |
Optional |
Specifies the size limit of the cache. The value represents the maximum number of units that can be placed in the cache before pruning occurs. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the Note: The value is limited to approximately 2GB by default. To specify higher values, use the |
|
< |
Optional |
Specifies the lowest number of units that a cache is pruned down to when pruning takes place. A pruning does not necessarily result in a cache containing this number of units; however, a pruning never results in a cache containing less than this number of units. An entry is the unit of measurement, unless it is overridden by an alternate unit calculator (see the |
|
< |
Optional |
Specifies the type of unit calculator to use. A unit calculator is used to determine the cost (in "units") of a given object. This element is used only if the
|
|
< |
Optional |
Specifies the factor by which the Note: This element was introduced only to avoid changing the type of the Valid values are positive integers. The default value is |
|
< |
Optional |
Specifies the amount of time since the last update that entries are kept by the cache before being expired. Entries that have expired are not accessible and are evicted the next time a client accesses the cache. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. A value of zero implies no expiry. The default value is Note: The expiry delay parameter ( |
|
< |
Optional |
Specifies an implementation of a |
Used in: caching-schemes, distributed-scheme.
The read-write-backing-map-scheme defines a backing map which provides a size limited cache of a persistent store. See Chapter 15, "Caching Data Sources" for more details.
The read-write-backing-map-scheme is implemented by the com.tangosol.net.cache.ReadWriteBackingMap class.
A read write backing map maintains a cache backed by an external persistent cache store (see <cachestore-scheme> subelement). Cache misses are read-through to the back-end store to retrieve the data. If a writable store is provided, cache writes are also propagate to the cache store.
When enabled (see <refreshahead-factor> subelement) the cache watches for recently accessed entries which are about to expire, and asynchronously reload them from the cache store. This insulates the application from potentially slow reads against the cache store, as items periodically expire.
When enabled (see <write-delay> subelement), the cache delays writes to the back-end cache store. This allows for the writes to be batched (see <write-batch-factor> subelement) into more efficient update blocks, which occur asynchronously from the client thread.
Table B-58 describes the subelements of the read-write-backing-map-scheme element.
Table B-58 read-write-backing-map-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies a custom implementation of the read write backing map. Any custom implementation must extend the |
|
Optional |
Specifies initialization parameters, for use in custom read write backing map implementations. |
|
|
Required |
Specifies a cache-scheme which is used to cache entries. Legal values are: |
|
|
|
Optional |
Specifies the maximum number of entries to write in a single |
|
< |
Optional |
Specifies a cache-scheme for maintaining information on cache misses. The miss-cache is used track keys which were not found in the cache store. The knowledge that a key is not in the cache store allows some operations to perform faster, as they can avoid querying the potentially slow cache store. A size-limited scheme may be used to control how many misses are cached. If unspecified no cache-miss data is maintained. Legal values are: |
|
Optional |
Specifies the store to cache. If unspecified the cached data only resides within the internal cache (see |
|
|
< |
Optional |
Specifies if the cache is read only. If |
|
|
Optional |
Specifies the time interval to defer asynchronous writes to the cachestore for a write-behind queue. The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed. If zero, synchronous writes to the cachestore (without queuing) take place, otherwise the writes are asynchronous and deferred by specified time interval after the last update to the value in the cache. The default value is zero. This element cannot be used with the |
|
|
Optional |
Specifies the number of seconds to defer asynchronous writes to the cachestore for a write-behind queue. If zero, synchronous writes to the cachestore (without queueing) take place; otherwise, the writes are asynchronous and deferred by the number of seconds after the last update to the value in the cache. This element cannot be used with the |
|
< |
Optional |
The
Conceptually, the write-behind thread uses the following logic when performing a batched update:
This element is only applicable if asynchronous writes are enabled (that is, the value of the write-delay element is greater than zero) and the |
|
< |
Optional |
Specifies the size of the write-behind queue at which additional actions could be taken. If zero, write-behind requeuing is disabled. Otherwise, this value controls the frequency of the corresponding log messages. For example, a value of 100 produces a log message every time the size of the write queue is a multiple of 100. Legal values are positive integers or zero. The default value is zero. |
|
< |
Optional |
The refresh-ahead-factor element is used to calculate the "soft-expiration" time for cache entries. Soft-expiration is the point in time before the actual expiration after which any access request for an entry schedules an asynchronous load request for the entry. This attribute is only applicable if the internal cache is a |
|
< |
Optional |
Specifies the timeout interval to use for (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. If |
|
< |
Optional |
Specifies whether exceptions caught during synchronous cachestore operations are rethrown to the calling thread (possibly over the network to a remote member). Legal values are |
|
< |
Optional |
Specifies an implementation of a |
Used in: tcp-initiator
The remote-addresses element contains the address (IP, or DNS name, and port) of one or more TCP/IP acceptors. A TCP/IP initiator uses this information to establish a connection with a proxy service on a remote cluster. TCP/IP acceptors are configured within the proxy-scheme element. The TCP/IP initiator attempts to connect to the addresses in a random order until either the list is exhausted or a connection is established. See Developing Remote Clients for Oracle Coherence for additional details and example configurations.
Note:
Thename-service-addresses element can also be used to establish a connection with a proxy service on a a remote cluster. For details, see "name-service-addresses".The following example configuration instructs the initiator to connect to 192.168.0.2:9099 and 192.168.0.3:9099 in a random order:
<remote-addresses>
<socket-address>
<address>192.168.0.2</address>
<port>9099</port>
</socket-address>
<socket-address>
<address>192.168.0.3</address>
<port>9099</port>
</socket-address>
</remote-addresses>
Table B-59 describes the subelements of the remote-addresses element.
Table B-59 remote-addresses Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the address (IP, or DNS name, and port) on which a TCP/IP acceptor is listening. Multiple |
|
|
Optional |
Specifies the address (IP, or DNS name, and port) on which a TCP/IP acceptor is listening or the configuration for a A |
Used in: cachestore-scheme, caching-schemes, near-scheme.
The remote-cache-scheme element contains the configuration information necessary to use a clustered cache from outside the cluster by using Coherence*Extend.
Table B-60 describes the subelements of the remote-cache-scheme element.
Table B-60 remote-cache-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service which manages caches created from this scheme. |
|
|
Optional |
Specifies the proxy service name to which this remote service connects. This element is only used if this remote service uses a name service to lookup a proxy service. For details on configuring a name service, see "name-service-addresses". The value must match the |
|
Optional |
Specifies the configuration information for a bundling strategy. |
|
|
Required |
Contains the configuration of the connection initiator used by the service to establish a connection with the cluster. |
|
|
|
Optional |
Specifies whether key association processing is done by the extend client or deferred to the cluster side. Valid values are |
|
<listener> |
Optional |
Specifies an implementation of a |
Used in: caching-schemes
The remote-invocation-scheme element contains the configuration information necessary to execute tasks within a cluster without having to first join the cluster. This scheme uses Coherence*Extend to connect to the cluster.
Table B-61 describes the subelements of the remote-invocation-scheme element.
Table B-61 remote-invocation-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service. |
|
|
Optional |
Specifies the proxy service name to which this remote service connects. This element is only used if this remote service uses a name service to lookup a proxy service. For details on configuring a name service, see "name-service-addresses". The value must match the |
|
Required |
Contains the configuration of the connection initiator used by the service to establish a connection with the cluster. |
Used in: caching-schemes, near-scheme, overflow-scheme
The replicated scheme defines caches which fully replicate all their cache entries on each cluster nodes running the specified service. See "Understanding Replicated Caches" for a detailed description of replicated caches.
Replicated caches support cluster wide key-based locking so that data can be modified in a cluster without encountering the classic missing update problem. Note that any operation made without holding an explicit lock is still atomic but there is no guarantee that the value stored in the cache does not change between atomic operations.
Storage for the cache is specified by using the backing-map scheme (see <backing-map> subelement). For instance, a replicated cache which uses a local-scheme for its backing map results in cache entries being stored in-memory.
Table B-62 describes the subelements of the replicated-scheme element.
Table B-62 replicated-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service which manages caches created from this scheme. Services are configured from within the |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is the |
|
Optional |
Specifies either: the class configuration information for a |
|
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies the duration of the standard lease in milliseconds. When a lease has aged past this number of milliseconds, the lock is automatically released. Set this value to zero to specify a lease that never expires. The purpose of this setting is to avoid deadlocks or blocks caused by stuck threads; the value should be set higher than the longest expected lock duration (for example, higher than a transaction timeout). It's also recommended to set this value higher than |
|
< |
Optional |
Specifies the lease ownership granularity. Legal values are:
A value of thread means that locks are held by a thread that obtained them and can only be released by that thread. A value of member means that locks are held by a cluster node and any thread running on the cluster node that obtained the lock can release it. The default value is the |
|
< |
Optional |
Specifies the maximum amount of time a client waits for a response before abandoning the original request. The request time is measured on the client side as the time elapsed from the moment a request is sent for execution to the corresponding server node(s) and includes the following:
Legal values are positive integers or zero (indicating no default timeout). The default value is the value specified in the |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
|
Optional |
Specifies the configuration information for a class that implements the The |
|
Optional |
Specifies what type of cache is used within the cache server to store the entries. Legal values are: To ensure cache coherence, the backing-map of a replicated cache must not use a read-through pattern to load cache entries. Either use a cache-aside pattern from outside the cache service, or switch to the |
|
|
< |
Optional |
Specifies an implementation of a |
|
< |
Optional |
The |
Used in: http-acceptor
The resource-config element contains the configuration information for a class that extends the com.sun.jersey.api.core.ResourceConfig class. The instance is used by the HTTP acceptor to load resource and provider classes for the Coherence REST application that is mapped to the specified context path. Multiple resource configuration classes can be configured and mapped to different context paths.
Table B-63 describes the subelements of the resource-config element.
Table B-63 resource-config Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies a root URI path for a REST application. The first character of the path must be |
|
|
Optional |
Contains the configuration information for a class that extends the |
Used in: acceptor-config, defaults, distributed-scheme, initiator-config, invocation-scheme, optimistic-scheme, replicated-scheme, transactional-scheme,
The serializer element contains the class configuration information for a com.tangosol.io.Serializer implementation.
The serializer element accepts either a reference to a serializer configuration or a full serializer configuration. The best practice is to reference a configuration which is defined in the operational configuration file. The operational configuration file contains two pre-defined serializer class configuration: one for Java (default) and one for POF. See "serializer".
The following example demonstrates referring to the POF serializer definition that is in the operational configuration file:
... <serializer>pof</serializer> ...
The following example demonstrates a full serializer class configuration:
...
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>my-pof-config.xml</param-value>
</init-param>
</init-params>
</instance>
</serializer>
...
Table B-64 describes the subelements of the serializer element.
Table B-64 serializer Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Contains the class configuration information for a |
Used in: address-provider, remote-addresses
The socket-address element specifies the address and port on which a TCP/IP acceptor is listening.
Table B-65 describes the subelements of the socket-address element.
Table B-65 socket-address Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Required |
Specifies the IP address (IP or DNS name) on which a TCP/IP acceptor socket is listening. If the address is a bind address, then the address may also be entered using CIDR notation as a subnet and mask (for example, |
|
< |
Required |
Specifies the port on which a TCP/IP acceptor socket is listening. Legal values are from 1 to 65535. |
Used in: tcp-acceptor, tcp-initiator, defaults, ssl, memcached-acceptor.
The <socket-provider> element contains the configuration information for a socket and channel factory. The socket providers that are configured within the <tcp-acceptor> and <tcp-initiator> elements are for use with Coherence*Extend. A socket provider that is configured within the <http-acceptor> element is used by Coherence REST. A socket provider that is configured within the <memcached-acceptor> element is used by memcached clients. Socket providers for TCMP are configured in an operational override within the <unicast-listener> element.
The <socket-provider> element accepts either a reference to a socket provider configuration or a full socket provider configuration. The best practice is to reference a configuration which is defined in the operational configuration file. See "socket-provider". The following socket providers are available: system (default), ssl, tcp, and sdp. Socket provider configurations are referred to using their id attribute name. The following example refers to the pre-defined SSL socket provider configuration:
<socket-provider>ssl</socket-provider>
The preconfigured override is tangosol.coherence.socketprovider.
Table B-66 describes the subelements you can define within the socket-provider element.
Table B-66 socket-provider Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies a socket provider that produces instances of the JVM's default socket and channel implementations. |
|
|
Optional |
Specifies a socket provider that produces socket and channel implementations which use SSL. |
|
|
Optional |
Specifies a socket provider that produces TCP-based sockets and channel implementations. |
|
|
Optional |
Specifies a socket provider that produce SDP-based sockets and channel implementations provided that the JVM and underlying network stack supports SDP. |
Used in: socket-provider.
The <ssl> element contains the configuration information for a socket provider that produces socket and channel implementations which use SSL.
Table B-67 describes the elements you can define within the ssl element.
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the name of the protocol used by the socket and channel implementations produced by the SSL socket provider. The default value is |
|
|
Optional |
Specifies the configuration for a security provider instance. |
|
|
Optional |
Specifies the configuration information for an implementation of the A |
|
Optional |
Specifies the configuration information for initializing an identity manager instance. |
|
|
Optional |
Specifies the configuration information for initializing a trust manager instance. |
|
|
|
Optional |
Specifies the configuration information for an implementation of the A |
|
Optional |
Specifies the configuration information for a delegate provider for SSL. Valid values are |
Used in: acceptor-config.
The tcp-acceptor element specifies the configuration information for a connection acceptor that accepts connections from Coherence*Extend clients over TCP/IP. See Developing Remote Clients for Oracle Coherence for additional details and example configurations.
Table B-68 describes the subelements of the tcp-acceptor element.
Table B-68 tcp-acceptor Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the configuration for a socket and channel factory. |
|
|
Optional |
Specifies the local address (IP, or DNS name, and port) on which the TCP/IP server socket (opened by the connection acceptor) is bound. |
|
|
Optional |
Specifies either the local address (IP, or DNS name, and port) on which the TCP/IP server socket is bound or an implementation of the A |
|
|
|
Optional |
Specifies whether a TCP/IP socket can be bound to an in-use or recently used address. This setting is deprecated because the resulting behavior is significantly different across operating system implementations. The JVM, in general, selects a reasonable default which is safe for the target operating system. Valid values are |
|
< |
Optional |
Indicates whether the |
|
< |
Optional |
Indicates whether TCP delay (Nagle's algorithm) is enabled on a TCP/IP socket. Valid values are |
|
< |
Optional |
Configures the size of the underlying TCP/IP socket network receive buffer.Increasing the receive buffer size can increase the performance of network I/O for high-volume connections, while decreasing it can help reduce the backlog of incoming data.The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is operating system dependent. |
|
< |
Optional |
Configures the size of the underlying TCP/IP socket network send buffer. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is operating system dependent. |
|
< |
Optional |
Configures the size of the TCP/IP server socket backlog queue. Valid values are positive integers. The default value is operating system dependent. |
|
|
Optional |
Specifies a value for the (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. The default value is |
|
Optional |
A collection of IP addresses of TCP/IP initiator hosts that are allowed to connect to this TCP/IP acceptor. |
|
|
|
Optional |
Specifies whether the suspect protocol is enabled to detect and close rogue Coherence*Extend client connections. The suspect protocol is enabled by default. Valid values are |
|
|
Optional |
Specifies the outgoing connection backlog (in bytes) after which the corresponding client connection is marked as suspect. A suspect client connection is then monitored until it is no longer suspect or it is closed to protect the proxy server from running out of memory. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is 10000000. |
|
|
Optional |
Specifies the outgoing connection backlog (in messages) after which the corresponding client connection is marked as suspect. A suspect client connection is then monitored until it is no longer suspect or it is closed to protect the proxy server from running out of memory. The default value is |
|
|
Optional |
Specifies the outgoing connection backlog (in bytes) at which point a suspect client connection is no longer considered to be suspect. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is 2000000. |
|
|
Optional |
Specifies the outgoing connection backlog (in messages) at which point a suspect client connection is no longer considered to be suspect. The default value is |
|
|
Optional |
Specifies the outgoing connection backlog (in bytes) at which point the corresponding client connection must be closed to protect the proxy server from running out of memory. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is 100000000. |
|
|
Optional |
Specifies the outgoing connection backlog (in messages) at which point the corresponding client connection must be closed to protect the proxy server from running out of memory. The default value is |
Used in: initiator-config.
The tcp-initiator element specifies the configuration information for a connection initiator that enables Coherence*Extend clients to connect to a remote cluster by using TCP/IP. See Developing Remote Clients for Oracle Coherence for additional details and example configurations.
Table B-69 describes the subelements of the tcp-initiator element.
Table B-69 tcp-initiator Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
Optional |
Specifies the configuration for a socket and channel factory. |
|
|
Optional |
Specifies the local address (IP, or DNS name, and port) on which the TCP/IP client socket (opened by the TCP/IP initiator) is bound. |
|
|
Optional |
Contains the address (IP, or DNS name, and port) of one or more name service TCP/IP acceptors. The TCP/IP connection initiator uses this information to establish a connection with a remote cluster. This element cannot be used if the |
|
|
Optional |
Contains the address (IP, or DNS name, and port) of one or more TCP/IP connection acceptors. The TCP/IP connection initiator uses this information to establish a connection with a remote cluster. This element cannot be used if the |
|
|
< |
Optional |
Specifies whether a TCP/IP socket can be bound to an in-use or recently used address. This setting is deprecated because the resulting behavior is significantly different across operating system implementations. The JVM, in general, selects a reasonable default which is safe for the target operating system. Valid values are |
|
< |
Optional |
Indicates whether the |
|
< |
Optional |
Indicates whether TCP delay (Nagle's algorithm) is enabled on a TCP/IP socket. Valid values are |
|
< |
Optional |
Configures the size of the underlying TCP/IP socket network receive buffer.Increasing the receive buffer size can increase the performance of network I/O for high-volume connections, while decreasing it can help reduce the backlog of incoming data.The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is operating system dependent. |
|
< |
Optional |
Configures the size of the underlying TCP/IP socket network send buffer.The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is operating system dependent. |
|
< |
Optional |
Deprecated. The |
|
|
Optional |
Specifies a value for the (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. The default value is |
Used in caching-schemes
The transactional-scheme element defines a transactional cache, which is a specialized distributed cache that provides transactional guarantees. Multiple transactional-scheme elements may be defined to support different configurations. Applications use transactional caches in one of three ways:
Applications use the CacheFactory.getCache() method to get an instance of a transactional cache. In this case, there are implicit transactional guarantees when performing cache operations. However, default transaction behavior cannot be changed.
Applications explicitly use the Transaction Framework API to create a Connection instance that uses a transactional cache. In this case, cache operations are performed within a transaction and the application has full control to change default transaction behavior as required.
Java EE applications use the Coherence Resource Adapter to create a Transaction Framework API Connection instance that uses a transactional cache. In this case, cache operations are performed within a transaction that can participate as part of a distributed (global) transaction. Applications can change some default transaction behavior.
Table B-70 describes the subelements of the transactional-scheme element.
Table B-70 transactional-scheme Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
< |
Optional |
Specifies the scheme's name. The name must be unique within a configuration file. |
|
< |
Optional |
Specifies the name of another scheme to inherit from. See "Using Scheme Inheritance" for more information. |
|
< |
Optional |
Specifies the name of the service which manages caches created from this scheme. The default service name if no service name is provided is |
|
|
Optional |
Specifies the priority for the service thread. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
|
Optional |
Specifies the priority for the event dispatcher thread for each service. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
Optional |
Specifies either: the class configuration information for a |
|
|
|
Optional |
Specifies the transport protocol used by this service for reliable point-to-point communication. Specifying a value results in the use of a service-specific transport instance rather then the shared transport instance that is defined by the
The default value is the |
|
< |
Optional |
Specifies the number of daemon threads used by the partitioned cache service. Legal values are positive integers, Specifying a thread count changes the default behavior of the Transactional Framework's internal transaction caches that are used for transactional storage and recovery. |
|
|
Optional |
Specifies the priority for the worker threads. Legal values are from 1 to 10 where 10 is the highest priority. The default value is |
|
< |
Optional |
Specifies whether a cluster node contributes storage to the cluster, that is, maintain partitions. When disabled the node is considered a cache client. Normally this value should be left unspecified within the configuration file, and instead set on a per-process basis using the tangosol.coherence.distributed.localstorage system property. This allows cache clients and servers to use the same configuration descriptor. Legal values are |
|
< |
Optional |
Specifies the number of partitions that a partitioned (distributed) cache is "chopped up" into. Each member running the partitioned cache service that has the local-storage ( The number of partitions should be a prime number and sufficiently large such that a given partition is expected to be no larger than 50MB. The following are good defaults for sample service storage sizes:
service storage partition-count
_______________ ______________
100M 257
1G 509
10G 2039
50G 4093
100G 8191
A list of first 1,000 primes can be found at Valid values are positive integers. The default value is the value specified in the |
|
|
Optional |
Specifies the transaction storage size. Once the transactional storage size is reached, an eviction policy is used that removes 25% of eligible entries from storage. The value of this element must be in the following format: (\d)+((.)(\d)+)?[K|k|M|m|G|g|T|t]?[B|b]? where the first non-digit (from left to right) indicates the factor with which the preceding decimal value should be multiplied:
If the value does not contain a factor, a factor of one is assumed. The default value is 10MB. |
|
< |
Optional |
Specifies the threshold for the primary buckets distribution in kilo-bytes. When a new node joins the partitioned cache service or when a member of the service leaves, the remaining nodes perform a task of bucket ownership re-distribution. During this process, the existing data gets re-balanced along with the ownership information. This parameter indicates a preferred message size for data transfer communications. Setting this value lower makes the distribution process take longer, but reduces network bandwidth utilization during this activity. Legal values are integers greater then zero. The default value is the |
|
< |
Optional |
Specifies the number of members of the partitioned cache service that hold the backup data for each unit of storage in the cache. A value of 0 means that for abnormal termination, some portion of the data in the cache is lost. The default value is the |
|
|
Optional |
Specifies the strategy that is used by a partitioned service to manage partition distribution. Valid values are |
|
< |
Optional |
Specifies the amount of time in milliseconds that a task can execute before it is considered "hung". Note: a posted task that has not yet started is never considered as hung. This attribute is applied only if the Thread pool is used (the |
|
< |
Optional |
Specifies the timeout value in milliseconds for requests executing on the service worker threads. This attribute is applied only if the thread pool is used (the |
|
< |
Optional |
Specifies the maximum amount of time a client waits for a response before abandoning the original request. The request time is measured on the client side as the time elapsed from the moment a request is sent for execution to the corresponding server node(s) and includes the following:
Legal values are positive integers or zero (indicating no default timeout). The default value is the value specified in the |
|
|
Optional |
Specifies the guardian timeout value to use for guarding the service and any dependent threads. If the element is not specified for a given service, the default guardian timeout (as specified by the The value of this element must be in the following format: (\d)+((.)(\d)+)?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of milliseconds is assumed. |
|
|
Optional |
Specifies the action to take when an abnormally behaving service thread cannot be terminated gracefully by the service guardian. Legal values are:
|
|
Optional |
Specifies quorum policy settings for the partitioned cache service. |
|
|
< |
Optional |
The element is intended to be used by cache servers (that is, |
Used in: ssl.
The <trust-manager> element contains the configuration information for initializing a javax.net.ssl.TrustManager instance.
A trust manager is responsible for managing the trust material that is used when making trust decisions and for deciding whether credentials presented by a peer should be accepted.
A valid trust-manager configuration contains at least one child element.
Table B-71 describes the elements you can define within the trust-manager element.
Table B-71 trust-manager Subelements
| Element | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
Specifies the algorithm used by the trust manager. The default value is |
|
|
Optional |
Specifies the configuration for a security provider instance. |
|
Optional |
Specifies the configuration for a key store implementation. |
Table B-72 describes the system property attribute that is available in the cache configuration deployment descriptor.
Table B-72 Cache Configuration Deployment Descriptor Attribute
| Attribute | Required/ Optional |
Description |
|---|---|---|
|
|
Optional |
This attribute is used to specify a system property name for any element. The system property is used to override the element value from the Java command line. This feature enables the same operational descriptor (and override file) to be used across all cluster nodes and customize each node using the system properties. See Appendix D, "System Property Overrides," for more information on this feature. |