2. Cache Scope
â—Ź The Cache Scope is a Mule feature for storing and reusing frequently called data.
The Cache Scope saves on time and processing load.
Overview:
â—Ź You can place any no of message processors into a cache scope and configure the
caching strategy to store the responses.
● Mule’s default caching strategy defines how data are stored and reused.
â—Ź But if you want to adjust cache behavior, you can customize a global caching
strategy in Mule and make it available for use by all cache scopes in your
application.
3. Behavior:
â—Ź Mule sends a message into the cache scope and the parent flow expects an output.
â—Ź The cache scope processes the message, delivers the output to the parent flow and
saves the output (that is, caches the response).
â—Ź The next time Mule sends the same kind of message into the cache scope, the cache
scope may offer a cached response rather than invoking, again, a potentially
time-consuming process.
Usage:
â—Ź You can use a cache scope to reduce the processing load on the Mule instance and
speed up message processing within a flow. It is particularly effective for:
-->Processing repeated requests for the same information.
-->Processing requests for information that involve large, non-consumable message
payloads.
4. Caching Strategy
â—Ź The caching strategy defines the actions a cache scope takes when a message enters
its sub flow.
-->If there is no cached response event (a cache “miss”), cache scope processes the
message.
-->If there is a cached response event (a cache “hit”), cache scope offers the cached
response event rather than processing the message.
â—Ź You can customize a global caching strategy in Mule for the cache scopes in your
application to follow, or you can use Mule’s default caching strategy.
Default Caching Strategy:
â—Ź A message enters the cache scope.
● Cache scope determines whether the message’s payload is consumable. A
consumable payload can only be read once before it is lost – such as a streaming
payload – and cannot be cached.
-->If the message payload is consumable, cache scope always processes the message;
nothing is cached and the caching strategy is abandoned.
-->If the message payload is not consumable, cache scope continues to the next step
in the caching strategy.
5. ● Cache scope generates a key to identify the message’s payload. Mule uses an
SHA256KeyGenerator and a SHA256 digest to generate a unique key for the
message payload.
â—Ź Cache scope compares the newly-generated key to cached responses that it has
previously processed and saved in an InMemoryObjectStore — a container for
cached data. In other words, cache scope searches for a “cache hit” it can offer
instead of processing the message.
-->Where there is a cache miss, cache scope processes the new message and
produces a response. Cache scope also saves the resulting response in the object
store. (If the response has a consumable payload, it does not cache the response.)
-->Where there is a cache hit, the caching strategy uses a DefaultResponseGenerator
to generate a response that combines data from both the new request and the cached
response. (If the generated response has a consumable payload, it does not cache the
response.)
â—Ź Cache scope pushes the response out into the parent flow for continued processing
6. Field Descriptions
â—Ź Display Name field - Value is Cache - Customize to display a unique name for the
scope in your application.
â—Ź Caching strategy reference
â—Ź Use Default caching strategy (Default) - Select if you want the cache scope to follow
Mule’s Default Caching Strategy.
â—Ź Reference to a strategy - Select to configure the cache scope to follow a global
caching strategy that you have created; select the global caching strategy from the
drop-down menu or create one by clicking the green plus sign.
â—Ź Filter field:
â—Ź Process all messages (Default) - Select if you want the cache scope to execute the
caching strategy for all messages that enter the scope.
â—Ź Filter messages using an expression - Select if you want the cache scope to execute
the caching strategy ONLY for messages that match the expression(s) defined in this
field.
â—Ź If the message matches the expression(s), Mule executes the caching strategy.
7. â—Ź If the message does not match expression(s), Mule processes the message
through all message processors within the cache scope; Mule never saves
nor offers cached responses.
â—Ź Filter messages using a global filter - Select if you want the cache scope to
execute the caching strategy only for messages that successfully pass
through the designated global filter.
â—Ź If the message passes through filter, Mule executes the caching strategy.
â—Ź If the message fails to pass through filter, Mule processes the message
through all message processors within the cache scope; Mule never saves
nor offers cached responses.
8. Configuring an Object Store for Cache
â—Ź By default, Mule stores all cached responses in an InMemoryObjectStore. Create a
Caching Strategy and define a new object store if you want to customize the way
Mule stores cached responses.
Field Descriptions:
â—Ź name (for in-memory, simple-text) --- Enter a unique name for your object store.
â—Ź storeName (for managed)
â—Ź persistent="true" --- Check to ensure that the object store saves cached responses in
persistent storage. Default is false.
â—Ź MaxEntries --- Enter an integer to limit the number of cached responses the object
store saves
â—Ź EntryTTL ---(Time To Live) Enter an integer to indicate the number of milliseconds
that a cached response has to live in the object store before it is expunged.
â—Ź Expiration Interval --- Enter an integer to indicate, in milliseconds, the frequency
with which the object store checks for cached response events it should expunge.
9. â—Ź Directory --- Enter the file path of the file where object store saves cached
responses
â—Ź NOTE: To enable synchronization, use the synchronized property in the
caching strategy element. Accepted values are true and false.
Invalidating a Cache:
â—Ź Removing the cache property that is already applied.
â—Ź Mule provides the InvalidatableCachingStrategy interface, which allows you to
invalidate a complete cache or a cache key without the need for custom code
or configuration
â—Ź There are two message processors for invalidating caches:
1)invalidate-cache - Completely invalidates a cache. Must reference an
invalidatable caching strategy.
EXAMPLE:
<ee:invalidate-cache cachingStrategy-ref="InvalidatableCachingStrategy"/>
10. â—Ź 2) invalidate-key - Calculates a cache key from the current event, then
searches for it in the cache and removes it if present. Must reference an
invalidatable caching strategy and, optionally, a MuleEventKeyGenerator. If
no MuleEventKeyGenerator is provided, Mule uses the default
implementation (SHA256MuleEventKeyGenerator).
EXAMPLE:
<ee:invalidate-key cachingStrategy-ref="InvalidatableCachingStrategy"
keyGenerator-ref="MD5MuleEventKeyGenerator"/>
