Replicated cache with Infinispan

[nimsys]

Hi,

I'm using a replicated cache with Infinispan on Wildfly 8. I'm using an idle time of 60 minutes, but at what actions is the idle time reset? I understand it's reset on write (or put) when the data is replicated to the other caches, but is it also reset on a read? I figured that since only one node in the cluster is affected it wouldn't be reset, but I'm not sure if last read time is replicated at that time.

I was actually looking for a method like "touch" because sometimes I don't need to do neither read or write but have to keep the entry in the cache because user is still logged in doing other stuff.

I couldn't find info about this in the docs, but I might have overlooked something.

Thanks,

Niclas

[nathandennis]

There is a MetaParam.MetaLastUsed (Infinispan JavaDoc API) in 9.1. I believe it was something like lastUsed in 7.0.. anyway.. im pretty sure the gist is the last access reset it.

[pferraro]

Infinispan's max-idle logic is based on a the lastUsed attribute of a cache entry's meta data (see infinispan/TransientMortalCacheEntry.java at 8.2.x · infinispan/infinispan · GitHub ).  While lastUsed is updated on both read and write (i.e. get and put), it is only replicated on write (not read), and therefore is not recommended for use with replicated/distributed caches.  This is a known limitation of Infinispan's max-idle based expiration.  See: Infinispan: Expiration Enhancements

[nimsys]

Thank you very much Paul for the answer. Yes the link you provided is very clear about it. It's a bit late to back out of the replicated solution now, so I guess we'll just have to stick with writes to keep entries alive

[pferraro]

There are some workarounds.  If you cache entries are particularly large, making superfluous writes expensive, you can split your entries into 2 (using key wrappers): one containing a single timestamp/counter that you always update using AdvancedCache.put(K, MetaData) with a maxIdle value, and the other immortal entry containing your value.  You can then use a expiration event to cascade the expiration of the timestamp entry to remove the corresponding entry containing your value.

[nimsys]

Nice workaround.

In plain text they can be about 100-200 kb but I Gzip them and store values as byte arrays which reduces the size by up to 90%.  Your solution seems even more effective though and I will definately consider it.

Thanks again!