4 Replies Latest reply on Mar 31, 2006 7:15 AM by Manik Surtani

    JBossCache 1.3 and Hibernate -- couple of questions

    Aaron Kardell Newbie

      We're still working on testing 1.3 with Hibernate. I have a couple of questions, if anyone can help with, I'd appreciate it.

      1) Is it okay to use optimistic node locking with REPLICATION_ASYNC, or is optimistic node locking only meant for use with INVALIDATION_ASYNC?

      2) Is there anything with 1.3 and/or INVALIDATION_ASYNC that might affect Hibernate's use of query caching? In our initial tests, query caching seems to be rather resource intensive, and I'm wondering if there's anything inherent to 1.3, invalidation, or optimistic locking that would make for a bad fit with query caching?

      Thanks!

      Aaron

        • 1. Re: JBossCache 1.3 and Hibernate -- couple of questions
          Aaron Kardell Newbie

          Well, good / bad news here...

          The good news is that by upgrading to Hibernate 3.2 CR 1 and using the OptimisticTreeCacheProvider instead of the default TreeCacheProvider, we were able to get past the basic issue of puts not taking effect in the cache (which was the root of issue #2 described below).

          The bad news is that we get a variety of new exceptions like the following:

          156000 [PoolThread-48] WARN org.jboss.cache.interceptors.TxInterceptor - Rolling back, exception encountered
          java.lang.RuntimeException:
           at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1033)
           at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:72)
           at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1443)
           at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:407)
           at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:224)
           at org.objectweb.jotm.Current.commit(Current.java:475)
           at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:325)
          .....
          Caused by: org.jboss.cache.CacheException: unable to validate nodes
           at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:109)
           at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:64)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:87)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:54)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:753)
           at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1011)
           ... 49 more
          


          followed immediately by many write lock exceptions:

          171000 [PoolThread-49] ERROR org.jboss.cache.lock.IdentityLock - write lock for /com/inventive/altona/orm/School could not be acquired after 15000 ms. Locks: Read lock owners: {}
          Write lock owner: GlobalTransaction:<10.40.58.21:3438>:1199
           (caller=GlobalTransaction:<10.40.58.21:3438>:1207, lock info: write owner=GlobalTransaction:<10.40.58.21:3438>:1199 (activeReaders=0, activeWriter=PoolThread-48, waitingReaders=0, waitingWriters=1, waitingUpgrader=0))
          171000 [PoolThread-49] WARN org.jboss.cache.interceptors.TxInterceptor - Rolling back, exception encountered
          java.lang.RuntimeException:
           at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1033)
           at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:72)
           at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1443)
           at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:407)
           at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:224)
           at org.objectweb.jotm.Current.commit(Current.java:475)
           at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:325)
           at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:136)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:153)
           at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4786)
           at org.jboss.cache.TreeCache.put(TreeCache.java:3224)
           at org.jboss.cache.TreeCache.put(TreeCache.java:2919)
           at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:95)
          .....
          Caused by: org.jboss.cache.lock.TimeoutException: write lock for /com/inventive/altona/orm/School could not be acquired after 15000 ms. Locks: Read lock owners: {}
          Write lock owner: GlobalTransaction:<10.40.58.21:3438>:1199
           (caller=GlobalTransaction:<10.40.58.21:3438>:1207, lock info: write owner=GlobalTransaction:<10.40.58.21:3438>:1199 (activeReaders=0, activeWriter=PoolThread-48, waitingReaders=0, waitingWriters=1, waitingUpgrader=0))
           at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:185)
           at org.jboss.cache.Node.acquireWriteLock(Node.java:557)
           at org.jboss.cache.Node.acquire(Node.java:517)
           at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:141)
           at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:68)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:54)
           at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
           at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:753)
           at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1011)
           ... 49 more
          


          In addition, it appears as though using the INVALIDATION_ASYNC actually causes all other nodes' caches to be emptied (invalidated) when one node's cache is written to with a put.

          Does anyone have any advice or anything I can try?

          Thanks!

          Aaron

          • 2. Re: JBossCache 1.3 and Hibernate -- couple of questions
            Manik Surtani Master

             

            "akardell" wrote:

            1) Is it okay to use optimistic node locking with REPLICATION_ASYNC, or is optimistic node locking only meant for use with INVALIDATION_ASYNC?


            You can use optimistic locking regardless of cache mode (LOCAL/REPL_SYNC/REPL_ASYNC/INVALIDATION_SYNC/INVALIDATION_ASYNC)

            "akardell" wrote:

            2) Is there anything with 1.3 and/or INVALIDATION_ASYNC that might affect Hibernate's use of query caching? In our initial tests, query caching seems to be rather resource intensive, and I'm wondering if there's anything inherent to 1.3, invalidation, or optimistic locking that would make for a bad fit with query caching?


            I can't think of anything specific here that would make it a bad fit - perhaps one of the Hibernate guys may care to comment here?

            • 3. Re: JBossCache 1.3 and Hibernate -- couple of questions
              Manik Surtani Master

               

              "akardell" wrote:

              In addition, it appears as though using the INVALIDATION_ASYNC actually causes all other nodes' caches to be emptied (invalidated) when one node's cache is written to with a put.


              Surely not the entire cache? E.g., if cache1 does a put on /a/b/c, other caches will only have /a/b/c invalidated, not, for example, /a/b/d?



              • 4. Re: JBossCache 1.3 and Hibernate -- couple of questions
                Manik Surtani Master

                The rollback exception you see is caused by

                Caused by: org.jboss.cache.CacheException: unable to validate nodes
                 at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInt
                erceptor.java:109)
                


                which is the result of 2 or more threads attempting to concurrently modify some data. Since data is optimistically locked (i.e., copied and versioned) there is always the potential for an exception like this to be thrown.

                Still though, with the new OptimisticTreeCacheProvider using the Option API (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheOptionsAPI) - specifically the failSilent option - this exception should not bubble up anywhere but simply be logged.