I've noticed that calling getAdvancedCache() in RemoteCacheManager results into an UnsupportedOperationException which means that locking a CacheEntry is impossible when using the HotRod-Client-Serverarchitecture. Is there any other way to enable locking, e.g. with VersioningAPI?
We need to perform the following operations atomicly:
- lock a key / entry
- obtain data from the cache
- e.g. modify existing entry / create new entry / do some lightweight business-operations
- release lock
Thanks for your help!
Side note: The reason why we need to switch to HotRod is that we must ensure the size of the available heap of our business-logic. We can't do this when running Cache and business-logic within the same JVM as mentioned in http://community.jboss.org/thread/165951?tstart=0 (https://issues.jboss.org/browse/ISPN-863) as the size of our cache-entries varies. (Please correct me if I'm wrong)
Thanks for the answer, but how do I put a not yet existent value with version into cache?
E.g. two RemoteCacheManager-instances invoke parallel RemoteCache.getVersioned on a not-yet-existent-value. Both clients will receive null for the given key. I can not use RemoteCache.replaceWithVersion because no such value exists, so I have to use RemoteCache.put which means that one value will be overridden by the other. Is there a way to handle this issue?
I'd like to have a feature where I can put a value with an initial version (say 0) which succeeds only if no such value exists.
The first time you can use remoteCache.putIfAbsent(key, value) (it's actually inherited from ConcurrentMap).
Unfortunately if that fails it returns a non-versioned value, if you want to retry you have to either use remoteCache.replace(key, oldValue, newValue), which calls equals() on the values, or do another remoteCache.getVersioned(key) so you can call replaceWithVersion. I suspect in most cases it would be better to use replace() and avoid the extra RPC.