You can enable near cache in your dynamic cache
provider so that an independent data grid exists on your dynamic cache
provider, serving as a fast cache for the remote, server-side cache.
About this task
Modify the backingMap of the objectgrid.xml file
to enable near cache in dynamic cache.
Procedure
- Add the following properties to the backingMap
of the objectgrid.xml file to enable near cache
on your dynamic cache provider: A near cache for a dynamic
cache must have the nearCacheEnabled, nearCacheInvalidationEnabled,
and nearCacheLastAccessTTLSyncEnabled properties
that are set to true; for example:
<backingMap name="IBM_DC_PARTITIONED_.*" template="true" readOnly="false"
< pluginCollectionRef="all" preloadMode="false" nearCacheEnabled="true"
nearCacheInvalidationEnabled="true" nearCacheLastAccessTTLSyncEnabled= "true"
lockStrategy="OPTIMISTIC"
copyMode="COPY_ON_READ_AND_COMMIT" ttlEvictorType="NONE" nullValuesSupported="false" />
Each
of the attributes on the backingMap element have the following definitions:
nearCacheEnabled
- 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: true (Optional)
nearCacheInvalidationEnabled
- Set the value to true to enable the removal
of stale data from the near cache as quickly as possible. Any update,
deletion, or invalidation operation against the data grid triggers
an asynchronous invalidation in the near cache. Because the invalidation
is asynchronous, client applications might access stale data for a
short time period after an update has occurred before the stale value
is removed from the near cache. To use near cache invalidation, the lockStrategy attribute
must be set to NONE or OPTIMISTIC.
Default: false (Optional)
nearCacheLastAccessTTLSyncEnabled
- Set the value to true to enable time-to-live
(TTL) information to be synchronized with the remote data grid. The LAST_ACCESS_TIME TTL
evictor type must be enabled when you enable this property.
Default: false (Optional)
- Optional: Configure the optimistic
locking strategy for maps that support applications, which use dynamic
cache.
The default lock strategy is OPTIMISTIC. Use
optimistic locking when data is changed infrequently. Locks are held
only during the short time period in which data is read from the cache
and copied to the transaction. When the transaction cache is synchronized
with the main cache, any cache objects that were updated are checked
against the original version. If the check fails, then the transaction
is rolled back and an OptimisticCollisionException exception results.
- Programmatically using the setLockStrategy method:
import com.ibm.websphere.objectgrid.BackingMap;
import com.ibm.websphere.objectgrid.LockStrategy;
import com.ibm.websphere.objectgrid.ObjectGrid;
import com.ibm.websphere.objectgrid.ObjectGridManagerFactory;
...
ObjectGrid og =
ObjectGridManagerFactory.getObjectGridManager().createObjectGrid("test");
BackingMap bm = og.defineMap("optimisticMap");
bm.setLockStrategy( LockStrategy.OPTIMISTIC );
- Using the lockStrategy attribute in the ObjectGrid descriptor XML file:
<?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="test">
<backingMap name="optimisticMap"
lockStrategy="OPTIMISTIC"/>
</objectGrid>
</objectGrids>
</objectGridConfig>
What to do next
By default, the maximum size of the dynamic near cache corresponds
to the maximum number of entries for a single partition in the remote
dynamic cache data grid. A least recently used (LRU) eviction algorithm
is used to maintain this size. To further control the size of the
near cache, you can take the following action:
- Configure the com.ibm.websphere.xs.dynacache.near_cache_size custom
property to specify the maximum number of cache entries that are allowed
in the near cache. For more information, see Dynamic cache custom properties.