Configuring locking strategies for the embedded global cache

You can configure your embedded global cache to use locking strategies to suit the types of data that you store in your cache.

1. Open the objectgrid.xml file, and configure the locking strategy for each backingMap entry by completing one of the following steps:
   • To configure the pessimistic locking strategy for a cache map, set the lockStrategy parameter to PESSIMISTIC.
     For example:

     <backingMap name="USER.PESSIMISTIC.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="PESSIMISTIC" copyMode="COPY_TO_BYTES"/>

   • To configure the optimistic locking strategy for a cache map, set the lockStrategy parameter to OPTIMISTIC_NO_VERSIONING. You can also set the nearCacheInvalidationEnabled parameter to true.
     For example:

     <backingMap name="USER.OPTIMISTIC.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="OPTIMISTIC_NO_VERSIONING" nearCacheInvalidationEnabled="true" copyMode="COPY_TO_BYTES"/>

   • To configure no locking for a cache map, set the lockStrategy parameter to NONE. You can also set the nearCacheInvalidationEnabled parameter to true.
     For example:

     <backingMap name="USER.NONE.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="NONE" nearCacheInvalidationEnabled="true" copyMode="COPY_TO_BYTES"/>

   Note: Enabling near-cache invalidation removes stale data from the cache as quickly as possible. For more information, see the WebSphere® eXtreme Scale documentation, https://www.ibm.com/support/knowledgecenter/SSTVLU_8.6.1/com.ibm.websphere.extremescale.doc/txsnearcacheinv.html.
   The following example file shows three entries, and includes an entry (SYSTEM.BROKER.*) that matches the default cache map for the IBM® App Connect Enterprise embedded global cache.

   Note: You can modify the locking strategy for the SYSTEM.BROKER.* entry but you must not remove the entry.

   <?xml version="1.0" encoding="UTF-8"?>
   <objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd" 
     xmlns="http://ibm.com/ws/objectgrid/config"> 
    <objectGrids>
     <objectGrid name="WMB">
      <backingMap name="USER.OPTIMISTIC.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="OPTIMISTIC_NO_VERSIONING" nearCacheInvalidationEnabled="true" copyMode="COPY_TO_BYTES"/>
      <backingMap name="USER.PESSIMISTIC.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="PESSIMISTIC" copyMode="COPY_TO_BYTES"/>
      <backingMap name="USER.NONE.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="NONE" nearCacheInvalidationEnabled="true" copyMode="COPY_TO_BYTES"/>
      <backingMap name="SYSTEM.BROKER.*" template="true" timeToLive="0" ttlEvictorType="LAST_UPDATE_TIME" lockStrategy="PESSIMISTIC" copyMode="COPY_TO_BYTES"/>
     </objectGrid>
    </objectGrids>
   </objectGridConfig>

   Note: If you add any additional backingMap entries, you must add the equivalent entries in the deployment.xml; see Optimizing the embedded global cache for use with different types of cache data. You cannot configure any other options in this file.
2. Save the objectgrid.xml file.
3. Configure the location of the objectgrid.xml file, by modifying the objectGridCustomFile property in the server.conf.yaml configuration file for the integration server.

   If you made changes to the deployment.xml file to keep the file consistent with the objectgrid.xml, you must also complete this step for your copy of the deployment.xml file. For information about the equivalent commands, see Configuring the embedded global cache to read data from replica shards of a cache map.

4. Restart the integration server for the changes to take effect.