--- schema_version: "1" id: 0aa1c18100cf7d866d83d20c6dc6fa261f47a65e810477495c8c9b8844c8fa3b title: Redis Connector 5.6 Additional Configuration Information collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/redis-connector/5.6/redis-connector-config-topics.md canonical_url: https://docs.mulesoft.com/redis-connector/5.6/redis-connector-config-topics source_site: docs.mulesoft.com content_type: documentation content_hash: e4b3355d35ac175f3395ee151cb1c3125664d34b946a755054469147051ac251 description: MuleSoft Documentation Site release: "5.6" latest: false --- --- product: Redis Connector version: 5.6 --- # Redis Connector 5.6 Additional Configuration Information > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Redis Connector contributes an object store implementation. Although Redis offers flexible eviction and persistence, you must understand how the Mule Redis-backed object store is designed to work when Redis is shared across multiple applications or systems. Learn key design constraints, eviction behavior, and best practices for using Redis as an object store in Mule applications, with a focus on avoiding deserialization and eviction-related failures. ## Redis as a Mule Object Store When Redis is configured as an object store in Mule: - Mule serializes payloads before storing them in Redis. - Object Store operations (retrieve, remove, expire) require successful deserialization of stored values. As a result, the Redis object store is designed to manage only entries that it created and can deserialize. ## Common Deployment Patterns In some architectures, Redis is deployed as a shared service and accessed by: - Multiple Mule applications - External (non-Mule) applications - Operational or administrative scripts that insert or delete keys This pattern is valid for Redis itself but introduces important considerations when Redis is used specifically as a Mule object store. ## Examples of Object Store Behavior Here are some scenarios of how the Redis object store behaves when Redis is shared across multiple applications or systems. ### In-Memory Object Store per Application ![App A and App B, each connecting to its own cloud service and dedicated database to store unique access and refresh tokens](/mulesoft/current/en-us/redis-connector/5.6/_images/redis-scenario-1.png) Setup - Application A and Application B each use an in-memory object store. Outcome - Each application maintains its own isolated store. - No key collisions or deserialization issues occur. - Expiration and invalidation are fully controlled per application. This is the safest and most isolated configuration. ### Shared External Object Store (Not Redis) ![App A and App B sharing a single database that stores multiple sets of access and refresh tokens](/mulesoft/current/en-us/redis-connector/5.6/_images/redis-scenario-2.png) Setup - Application A and Application B use a common external object store. - Identical object IDs (for example, access\_token) are used. Outcome - Redis object store implementation prevents overwriting entries created by another application. - This behavior is intentional to prevent data corruption. Cross-application data ownership is restricted by design. ### Redis as a Shared External Object Store ![App A and App B both connecting to a centralized Redis database while also maintaining individual connections to Salesforce and ServiceNow](/mulesoft/current/en-us/redis-connector/5.6/_images/redis-scenario-3.png) Setup - Redis is configured as a shared external object store. - Mule Application A, Application B, and external systems write to the same Redis instance. - Stored data includes: - Java-serialized objects (via Mule object store) - Plain text or JSON (via direct Redis operations) Outcome - During eviction or expiration, the Mule object store might encounter entries it can’t deserialize. - This can result in errors such as: ```text org.mule.runtime.api.store.ObjectStoreException: Could not deserialize object Caused by: java.lang.ClassNotFoundException ``` Eviction or cleanup fails when Redis contains entries not owned by the current application or classloader. ## Expectation vs. Actual Behavior
ExpectationActual Behavior

Redis object store can be freely shared across applications.

Each application can only deserialize objects created within its own classloader.

Expiration task cleans all excess entries.

Expiration fails when encountering unknown or incompatible entries.

Non-Mule data can coexist in Redis.

Non-serialized data can cause object store failures.

Cache Scope can be invalidated across applications.

Cache invalidation is application-bound.

## Why This Behavior Is by Design The Redis object store follows strict safety and isolation principles:
Design PrincipleExplanation

Data Ownership

Manages only data that the object store owns

Data Integrity

Prevents accidental deletion of external or foreign data

Classloader Isolation

Deserializes objects only from its own Mule application

Fail-Safe Operation

Fails safely instead of performing destructive deletes

This ensures predictable behavior and avoids unintended side effects in shared environments. ## Redis Eviction and Mule Object Store Redis eviction policies operate at the Redis level, not at the Mule object store level. Mule object store expiration deserializes values even during expiration. As a result, Mule object store expiration can fail if incompatible entries exist. ## Recommended Best Practices - Separate Object Store and Generic Redis Usage - Use object store APIs only for Mule-managed, serialized data stored in Redis object store. - Use Redis Connector operations for plain text, JSON, or external data. - Namespace Keys Explicitly - For shared Redis object store, ensure object store keys don’t overlap with externally managed Redis keys.