Storing entries in the cache under multiple keys

[jugglingcats]

Hi, I have a scenario where we have a main key for objects in the cache, but a need for one or more "secondary" keys, which will be used to lookup entries (far less frequently).

I would like to check my assumption that with a replicated or distributed cache, if I store the same Java object in two different caches (or in the same cache under two keys?), it will end up duplicated as it goes over to other members of the cluster. This will lead to issues both in terms of memory consumption and behaviour (updates to object in one cache won't be seen in the other).

In which case, is the 'normal' practice to store a lightweight object in the secondary cache pointing to the primary cache key, ie:

main cache

main_key ==> [entry]

secondary cache

secondary_key ==> main_key

I can imagine this might cause issues in terms of consistency (eg. expiry) between the caches, but don't think this is a big issue for our use case.

Any advice appreciated.

Thanks, Alfie.

[wdfink]

I'm not sure about your the use-case, just sharing my thoughts

From the technical side there might have a performance problem if you access the cache remote as you need two invocations.

On the other hand side if you have local access and you use a distrubuted cache (only a couple of instances store the cache do save memory) the secondary and main cache object might stored on different instances and there is a remote access to retrive the entry.

If you store the same Java Object with different Keys you might spend memory.

You might use a transactional cache to avoid different objects for the same secondary/main key

[rhusar]

+1

In which case, is the 'normal' practice to store a lightweight object in the secondary cache pointing to the primary cache key, ie:

I don' think it's a typical practice, but the consistency concern is solvable by transactions.