BigMemory Max 4.3.5 | Product Documentation | BigMemory Max Developer Guide | Refresh Ahead | Scheduled Refresh Ahead
 
Scheduled Refresh Ahead
You can configure refresh-ahead operations to occur on a regular schedule using Quartz scheduled jobs. These jobs can asynchronously load new values using configured cache loaders on a schedule defined by a cron expression. This type of refresh operation is useful when all or a large portion of a cache's data must be updated regularly.
Note that at least one CacheLoader must be configured for caches using scheduled refresh. For information about configuring a cache loader, see Implementing the CacheLoader.
Configuring Scheduled Refresh
Scheduled refresh ahead is configured using a cache extension. For information about using cache extensions, see Cache Extensions.
<cache ...

<cacheLoaderFactory class="com.company.my.ConcreteCacheLoaderFactory"
properties="some_property=1, some_other_property=2" />
<cacheExtensionFactory
class="net.sf.ehcache.constructs.scheduledrefresh.ScheduledRefreshCacheExtensionFactory"
properties="batchSize=100;
quartzJobCount=2;
cronExpression=0 0 12 * * ?"
propertySeparator=";"/>
...
</cache>
Because a cron expression can contain commas (","), which is the default delimiter for properties, the propertySeparator attribute can be used to specify a different delimiter.
The cache-extension class is required for implementing the refresh-ahead mechanism. This cache extension is responsible for instantiating a dedicated Quartz scheduler with its own RAMJobStore for each non-clustered cache configured for scheduled refresh ahead. For information about RAMJobStores, see "Working with JobStores" in the Quartz Scheduler Developer Guide.
Note that scheduled-refresh configuration properties are optional unless marked REQUIRED. The following table describes these properties. Classes are found in net.sf.ehcache.constructs.scheduledrefresh.
Property
Definition
Default Value
cronExpression
REQUIRED. This is a string expression, in cron format, dictating when the refresh job should be run. For information about creating cron triggers, see "Working with Triggers" in the Quartz Scheduler Developer Guide.
N/A
batchSize
(Integer) This is the number of keys which a single job will refresh at a time as jobs are scheduled.
100
keyGenerator
If null, SimpleScheduledRefreshKeyGenerator is used to enumerate all keys in the cache. Or, to filter the keys to be refreshed, provide a class that implements the ScheduledRefreshKeyGenerator interface, overriding its generateKeys() method.
Null
useBulkLoad
If this is true, the node will be put in bulkload mode as keys are loaded into the cache. For information about bulk loading, see Bulk Loading.
false
quartzJobCount
Controls the number of threads in the Quartz job store created by this instance of ScheduleRefreshCacheExtension. At least 2 threads are needed, 1 for the controlling job and 1 to run refresh batch jobs. There is always an additional thread created with respect to the value set. Therefore the default value of "2" creates the controlling job (always created) and 2 worker threads to process incoming jobs.
2
scheduledRefreshName
By default, the underlying Quartz job store is named based on a combination of CacheManager and cache names. If two or more ScheduledRefreshExtensions are going to be attached to the same cache, this property provides a necessary way to name separate instances.
Null
evictOnLoadMiss
A boolean to force an immediate eviction on a reload miss (true) or to not evict before normal eviction takes effect (false). If true, entries that do not refresh due to a failure of the reload operation (all cacheloaders fail) are evicted even if they have not expired based on time-to-live or time-to-idle settings.
true
jobStoreFactory
By default, a RAMJobStore is used by the Quartz instance. To define a custom job store, implement the ScheduledRefreshJobStorePropertiesFactory interface.
See Note below.
tcConfigUrl
The URL to a Terracotta server in the form <server-address>:<tsa-port>, same as the Quartz property org.quartz.jobStore.tcConfigUrl. Setting this allows the Quartz instances supporting scheduled refresh to run distributed in a Terracotta cluster.
N/A
parallelJobCount
Maximum number of simultaneous refresh batch jobs that can run when Quartz instances supporting scheduled refresh run distributed in a Terracotta cluster. Tune this value to improve performance by beginning with a value equal to the number of (identical) distributed scheduled-refresh nodes multiplied by the total number of Quartz nodes. For example, if there are 4 instances and 4 Quartz nodes, set this value to 16 and confirm that resources are not being overly utilized. If resources are still underutilized, increase this value and gauge the impact on resources and performance.
Equals the value of quartzJobCount.
Note: The default jobStoreFactory is ScheduledRefreshRAMJobStoreFactory. However, if the property tcConfigUrl is specified, the jobStoreFactory used is ScheduledRefreshTerracottaJobStoreFactory.
Copyright © 2010 - 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release