Configuring an enterprise data grid for dynamic caching using a Liberty profile

A Liberty server can host a data grid that caches data for applications that have dynamic cache enabled.

1. Enable the WebSphere eXtreme Scale dynamic cache feature.
   1. Add the dynamic cache feature to the Liberty server.xml file.
      For example, your server.xml file resembles the following stanza of code:

      <featureManager>
      <feature>eXtremeScale.server-1.1</feature>
      <feature>eXtremeScale.dynacacheGrid-1.1</feature>
      </featureManager>

2. Optional: Set properties on the xsDynacacheGrid element in the server.xml file.
   You can change any of the following properties; however, it is recommended that you accept the default values.

   globalIndexDisabled

   Global index invalidation improves invalidation efficiency in a large, partitioned environment; for example, more than 40 partitions. For more information, see Data invalidation. Default value: false

   objectGridName

   A string that specifies the name of the data grid. Default value: DYNACACHE_REMOTE. For more information, see ObjectGrid descriptor XML file and Deployment policy descriptor XML file.

   ojectGridTxTimeout

   Specifies the amount of time in seconds that a transaction is allowed for completion. If a transaction does not complete in this amount of time, the transaction is marked for rollback and a TransactionTimeoutException exception results. Default value: 30 (in seconds)

   backingMapLockStrategy

   Specifies if the internal lock manager is used whenever a map entry is accessed by a transaction. Set this attribute to one of three values: OPTIMISTIC, PESSIMISTIC, or NONE. Default value: PESSIMISTIC

   backingMapCopyMode

   Specifies if a get operation of an entry in the BackingMap instance returns the actual value, a copy of the value, or a proxy for the value. If you use eXtreme data format (XDF) so that both Java and .NET can access the same data grid, then the default and required copy mode is COPY_TO_BYTES. Otherwise, the copy mode, COPY_ON_READ_AND_COMMIT is used. Set the CopyMode attribute to one of five values:

   COPY_ON_READ_AND_COMMIT

   The default value is COPY_ON_READ_AND_COMMIT. Set the value to COPY_ON_READ_AND_COMMIT to ensure that an application never has a reference to the value object that is in the BackingMap instance. Instead, the application is always working with a copy of the value that is in the BackingMap instance. (Optional)

   COPY_ON_READ

   Set the value to COPY_ON_READ to improve performance over the COPY_ON_READ_AND_COMMIT value by eliminating the copy that occurs when a transaction is committed. To preserve the integrity of the BackingMap data, the application commits to delete every reference to an entry after the transaction is committed. Setting this value results in an ObjectMap.get method returning a copy of the value instead of a reference to the value, which ensures changes that are made by the application to the value does not affect the BackingMap element until the transaction is committed.

   COPY_ON_WRITE

   Set the value to COPY_ON_WRITE to improve performance over the COPY_ON_READ_AND_COMMIT value by eliminating the copy that occurs when ObjectMap.get method is called for the first time by a transaction for a given key. Instead, the ObjectMap.get method returns a proxy to the value instead of a direct reference to the value object. The proxy ensures that a copy of the value is not made unless the application calls a set method on the value interface.

   NO_COPY

   Set the value to NO_COPY to allow an application to never modify a value object that is obtained using an ObjectMap.get method in exchange for performance improvements. Set the value to NO_COPY for maps associated with EntityManager API entities.

   COPY_TO_BYTES

   Set the value to COPY_TO_BYTES to improve memory footprint for complex Object types and to improve performance when the copying of an Object relies on serialization to make the copy. If an Object is not Cloneable or a custom ObjectTransformer with an efficient copyValue method is not provided, the default copy mechanism is to serialize and inflate the object to make a copy. With the COPY_TO_BYTES setting, inflate is only performed during a read and serialize is only performed during commit.

   Default value: COPY_ON_READ_AND_COMMIT

   backingMapNearCacheEnabled

   Set the value to true to enable the client local cache. To use a near cache, the lockStrategy attribute must be set to NONE or OPTIMISTIC. Default value: false

   mapSetNumberOfPartitions

   Specifies the number of partitions for the mapSet element. Default value: 47

   mapSetMinSyncReplicas

   Specifies the minimum number of synchronous replicas for each partition in the mapSet. Shards are not placed until the domain can support the minimum number of synchronous replicas. To support the minSyncReplicas value, you need one more container server than the minSyncReplicas value. If the number of synchronous replicas falls below the minSyncReplicas value, write transactions are no longer allowed for that partition. Default value: 0

   mapSetMaxSyncReplicas

   Specifies the maximum number of synchronous replicas for each partition in the mapSet. No other synchronous replicas are placed for a partition after a domain reaches this number of synchronous replicas for that specific partition. Adding container servers that can support this ObjectGrid can result in an increased number of synchronous replicas if your maxSyncReplicas value has not already been met. Default value: 0

   mapSetNumInitialContainers

   Specifies the number of container servers that are required before initial placement occurs for the shards in this mapSet element. This attribute can help save process and network bandwidth when bringing a data grid online from a cold startup. Default value: 1

   mapSetDevelopmentMode

   With this attribute, you can influence where a shard is placed in relation to its peer shards. When the developmentMode attribute is set to false, no two shards from the same partition are placed on the same computer. When the developmentMode attribute is set to true, shards from the same partition can be placed on the same machine. In either case, no two shards from the same partition are ever placed in the same container server. Default value: false

   mapSetReplicaReadEnabled

   If this attribute is set to true, read requests are distributed among a partition primary and its replicas. If the replicaReadEnabled attribute is false, read requests are routed to the primary only. Default value: false

   .
3. Configure WebSphere Application Server to point to the Liberty.

   You can connect WebSphere eXtreme Scale containers and dynamic-cache-enabled web applications to a catalog service domain that is running in another WebSphere Application Server cell or as stand-alone processes. Because remotely configured catalog servers do not automatically start in the cell, you must manually start any remotely configured catalog servers.

   When you configure a remote catalog service domain, the domain name must match the domain name that you specified when you start the remote catalog servers. The default catalog service domain name for stand-alone catalog servers is DefaultDomain. Specify a catalog service domain name with the startOgServer or startXsServer command -domain parameter, a server properties file, or with the embedded server API. You must start each remote catalog server process in the remote domain with the same domain name. For more information about starting catalog servers, see Starting a stand-alone catalog service that uses the ORB transport.