Redis Connector 5.6 Additional Configuration Information

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

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

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

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:

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

Expectation	Actual 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.

Expectation

Actual 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 Principle	Explanation
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

Design Principle

Explanation

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.