Shared Cache Settings¶
The shared cache is a key/value store that channels read and write from scripts. This setting decides where a shared cache value is kept by default: in the JVM's memory, or in the QIE database. The choice determines whether the cache works across a cluster, and what kinds of object you are allowed to put in it.
Find it under System Administration -> System Configuration, in the Advanced Settings section (click Show Advanced Settings).
The scripting side of the shared cache is covered by the Shared Cache Object: the functions, the namespace and global parameters, and the per-call override described below.
Default Storage¶
Default Storage: Either In-Memory or Persisted.
- In-Memory: Values live in the JVM of the instance that set them. Nothing is written to the database, so nothing survives a restart and nothing is visible to any other instance.
- Persisted: Values are written to the QIE database, so they survive a restart and every instance in a cluster sees the same value.
The three read-only fields beside it restate the consequences of that choice, so you can see the trade before you save:
| Default Storage | HA Compatible | Non-serializable | Serializable |
|---|---|---|---|
Persisted |
Yes | No | Yes |
In-Memory |
No | Yes | Yes |
Read that table as the whole trade-off: Persisted buys you a cluster-wide cache and costs you the ability to store non-serializable objects. In-Memory is the reverse. Serializable objects are accepted either way.
High availability¶
In an EnterpriseHA cluster each instance runs its own JVM, so an in-memory value set on one node does not exist on any other. If channels depend on a shared cache value being visible cluster-wide, Default Storage must be Persisted.
Serializable objects only, when persisted¶
Writing to the database means the value has to be serialized. Storing a non-serializable object while the default is Persisted raises an exception at the point of the call. It does not fail quietly or fall back to memory. Scripts that cache things like an open connection, a stream, or a parsed third-party object are the usual casualties.
Saving a change clears the cache
Changing Default Storage discards all current shared cache values, both In-Memory and Persisted. This is not a migration. Nothing is copied from one store to the other. Any channel that expects a value it wrote earlier finds it missing on the next read. Treat this as a change to make during a maintenance window, not on a running production system.
Mutexes use this setting too¶
The same default governs getMutex() and releaseMutex(). This matters more than it first appears: a mutex is normally used to stop two things happening at once, and an in-memory mutex in a clustered environment only locks out the instance that holds it. Every other node acquires its own copy and proceeds, which defeats the point of taking the lock.
Warning
If you use mutexes to serialize work across an EnterpriseHA cluster, Default Storage must be Persisted. An in-memory mutex appears to work in testing on a single node and then fails to exclude anything in production.
Overriding the default per call¶
This setting is only the default. Shared cache and mutex functions accept an explicit persist argument, and passing true or false there wins over the system setting for that one call. That is the right tool when most of a system's cache usage suits one mode but a particular value needs the other (e.g. a large non-serializable object held in memory on an otherwise-persisted system).
Clear Shared Cache¶
The Clear Shared Cache button discards every shared cache value immediately, without changing the Default Storage setting.
Use with caution
Clearing the shared cache is immediate and cannot be undone. Running channels are not warned and not paused: a channel that reads a cleared key gets nothing back, and whether that is harmless or produces a bad message depends entirely on how the script handles a missing value. Confirm what the channels on this system keep in the shared cache before using this on production.