0 Replies Latest reply on Jun 21, 2010 12:58 PM by sunnyos

    Pessimistic locking iso=NONE to MVCC causing issues

    sunnyos


      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)
              ..........