Pessimistic locking iso=NONE to MVCC causing issues
sunnyos Jun 21, 2010 12:58 PM
Hi All,
I was using version 2.1.0 with Node locking set to "Pessimistic Locking" and isolation level = "NONE". I have now upgraded to the 3.2.5 version.
The application is a multi threaded J2EE - MDB (multiple instance > 200) application. At a time there can be multiple threads attempting to insert and/or read from the cache. The data does not change very often and I do not care if the data is stale as we expire the cache every 20 mins and any processing with stale data occurs we can correct it offline. So staleness of data is not an issue.
I have a few questions:
1) This version 3.2.5GA has depreciated pessimistic and optimistic locking: What does this mean? Is this safe to use the same configuration? Pessimistic + Isolation="None"
2) When testing with MVCC I noticed the following exception (full stack pasted below) and a transaction rollback:
org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/xxxxx] after [20000] milliseconds for requestor
- I also noticed the performance of the application as highly degraded towards the end of the (stress) test as many threads were locked
3) Is there an alternative which will allow us to use the current version with no locking / "none" isolation level without using a depricated part of the API. Or is it safe to use pessimistic logging.
4) Assuming currently, pessimistic locking with NONE isolation works for us, what is the future plan for the API as we intend on upgrading to newer version but would not like locking.
================================================
STACK
=====
Target exception stack trace:
org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/getAccountByAltID] after [20000] milliseconds for requestor [GlobalTransaction:<null>:547]! Lock held by [GlobalTransaction:<null>:544]
at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:197)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101)
at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555)
..........