This content has been marked as final. Show 6 replies
Whilst doing some Profiling on our code, I noted that (in some cases) much of the time taken to "get" from a Replicated Cache is spent on acquiring a Lease. My understanding of the Lease Model is somewhat limited to the following piece of documentation, so apologies if I'm asking ignorant questions:
Is there any further explanation on how this works? In particular, I'm wondering why Coherence would need to obtain a lease on a simple "get". My underlying data is read-mostly, write-rarely, and a low retrieval time is very important to the application. Is there any way of turning this off, and would it ever be advised?
Edited by: 899446 on 19-Nov-2012 04:38
Edited by: 899446 on 19-Nov-2012 04:39
If I correctly remember this peculiarity, in Coherence replicated caches the existence of an acquired lock for a key or an InvocableMap.process() method for a key (which acquires a lock) blocks a concurrent get for the same key. Can it be possible that in those cases you see, this is what is actually happening?
No, we never lock or run Entry Processors against these caches. We only ever putAll() and get(). I've included some profiling output as an example of my findings:
9,996 µs - 100 inv. com.myproject.MyCacheDao.get + 9,446 µs - 100 inv. com.tangosol.coherence.component.util.SafeNamedCache.get ++ 8,825 µs - 100 inv. java.util.Map.get +++ 8,782 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.get ++++ 8,728 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.getCachedResource +++++ 7,182 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.getLease +++++ 1,025 µs - 100 inv. java.util.Map.get
try to repeat your test with override like this -1 person found this helpful
<coherence> <cluster-config> <services> <service id="1"> <init-params> <init-param id="lease-overflow"> <param-name>graveyard-size</param-name> <param-value>0</param-value> </init-param> </init-params> </service> </services> </cluster-config> </coherence>
I've done some provisional testing using the config you've supplied, and so far the results are promising - the amount of time taken to acquire the lease has dropped dramatically!
Could you tell me:
1. What does this configuration do?
2. Where is the official documentation describing this?
3. What possible issues could this cause?
4. Is this configuration supported for Production use?
Any chance of an update on this? I'd really like to put this into Production, but can't really do so until I understand what this change does.
It changes internal implementation of a lease map to a simple HashMap, and yes, it is perfectly fine to use it in production.