JBossCache 1.3 and Hibernate -- couple of questions

[akardell]

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

[akardell]

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

[manik]

"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?

[manik]

"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?

[manik]

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.