--- schema_version: "1" id: 74e690a67c1ed5b28e75cc0b256beb8d9e69d58bfca5f21e4543a14eee5c1046 title: Set Up a Caching Strategy collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/latest/cache-scope-strategy.md canonical_url: https://docs.mulesoft.com/mule-runtime/latest/cache-scope-strategy source_site: docs.mulesoft.com content_type: documentation content_hash: 204d59bff1708720c8e685edea070d4cf65151fa200bf6111e1dfab8034ffe1c description: MuleSoft Documentation Site release: "4.13" latest: true --- --- product: Mule Runtime version: 4.13 is-latest-version: true --- # Set Up a Caching Strategy > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can create a caching strategy from a Cache scope properties panel or a Global Elements configuration in Anypoint Studio. After you create a strategy, a Cache component in your flow can reference it. You can configure the cache size, expiration time, and maximum allowed entries by setting these values in the object store that you define or reference from the caching strategy. Follow these steps to configure a caching strategy: 1. Open the caching strategy configuration window. You can open it from the Cache scope properties panel or the **Caching Strategies** option in the Global Elements tab within Studio: ![A Caching Strategy setup with options for object store and event key generation](/mulesoft/current/en-us/mule-runtime/latest/_images/mruntime-caching-strategy.png) 2. Define the **Name** of the caching strategy. 3. Define the **ObjectStore** to use by selecting any of the following options: - **Edit Inline** Use this option to create an Object Store configuration specific for this caching strategy. - **Global Reference** Use this option either to select an existing Object Store, or to create a new global Object Store that can be referenced by this caching strategy and any other component in your application. 4. Select a mechanism for generating a key for storing messages within the caching strategy: - **Default** - **Key Expression** A DataWeave expression (for example, `keyGenerationExpression="#[vars.requestId]"`). For two requests that are the same ("equal"), generate the same key. Otherwise, you can get wrong results. - **Key Generator** (deprecated) > [!WARNING] Key Generator is deprecated. It requires implementing the > `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator` interface, which operates on > the full Mule event. > > Applications with a `minMuleVersion` of 4.13 or later can’t use Key Generator: Anypoint > Studio doesn’t show this option, and deploying such an application fails if it’s configured. > Applications with an earlier `minMuleVersion` can continue to use Key Generator. 5. (Optional) Open the **Advanced** tab in the properties window to configure advanced settings (deprecated): > [!WARNING] The Response Generator and Event Copy Strategy settings on the **Advanced** tab are > deprecated. Both require a Java implementation that operates on the full Mule event. For > example, Response Generator requires implementing the > `com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator` interface. > > Applications with a `minMuleVersion` of 4.13 or later can’t use these settings: Anypoint > Studio doesn’t show the **Advanced** tab, and deploying such an application fails if either > setting is configured. Applications with an earlier `minMuleVersion` can continue to use these > settings. ![A configuration panel for a caching strategy showing settings for cache behavior and response generator](/mulesoft/current/en-us/mule-runtime/latest/_images/mruntime-caching-strategy-advanced.png) - Select or create a **Response Generator**. This step requires implementing the `com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator` interface. - Select the **Event Copy Strategy**: - **Simple event copy strategy** Data is immutable. This is the default value. - **Serializable event copy strategy** Data is mutable. If you leave **Event Copy Strategy** set to `None`, Mule applies the default, **Simple event copy strategy**. ## Synchronized Access to a Cache By default, Mule synchronizes access to a cache to avoid unexpected results if multiple message processors (on the same or different Mule instances) use the cache at the same time. Consider a scenario where two message processors attempt to retrieve a value from a cache but do not find the value in the cache. So each message processor calculates the value independently and inserts it into the cache. If access to the cache is not synchronized, the value inserted by the second message processor overwrites the value inserted by the first message processor. If the values are different, then two different results are obtained for the same input, with only the last one stored in the cache. In some scenarios this outcome is valid, but it can be a problem if the application requires cache coherence. Synchronizing the caching strategy ensures this coherence. A synchronized cache is locked when it is being modified by a message processor. In the previous scenario, a locked cache forces the second message processor to wait until the first message processor has calculated the value, and then it retrieves the value from the cache. You can disable cache synchronization by defining the `synchronized` property in the `` element and setting it to `false`. > [!IMPORTANT] Synchronization affects performance, and the impact is most severe in cluster mode. ## Message Serialization The Cache scope persists only the message (payload and attributes) in the caching strategy’s object store, not the full Mule event. This reduces the amount of data the Cache scope serializes and avoids issues caused by internal event objects, such as completion callbacks and locks, that aren’t meant to be serialized. The `mule.serialize.message.in.cache` feature flag controls this behavior. See [Feature Flagging Mechanism](https://docs.mulesoft.com/mule-runtime/latest/feature-flagging). > [!IMPORTANT] Applications with a `minMuleVersion` earlier than 4.13 continue to persist the full > Mule event instead of the message. This behavior is controlled by the > `mule.serialize.message.in.cache` feature flag. See > [Feature Flagging Mechanism](https://docs.mulesoft.com/mule-runtime/latest/feature-flagging). > > If the Cache scope finds an entry serialized in the older, full-event format when reading from the > object store, it replaces that entry with the message-only format after use. Existing entries are > migrated on demand as they’re accessed, rather than all at once. > > After an entry is persisted in the message-only format, it can’t be read by an earlier Mule > runtime version. To roll back to an earlier Mule runtime version, clear the caching strategy’s > object store first. ## Example Caching Strategy The following XML snippet shows the configuration of a caching strategy that synchronizes access to the cache, and defines a persistent Object Store to store the cached responses. The caching strategy is then referenced by a Cache scope: ```xml ``` ## See Also - [Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope) - [Configure the Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope-to-configure) - [Object Store Configuration](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores#object-store-config) - [Global Elements](https://docs.mulesoft.com/mule-runtime/latest/global-elements) - [Feature Flagging Mechanism](https://docs.mulesoft.com/mule-runtime/latest/feature-flagging)