Hello All,

I am using Hibernate (2.1.4), JBoss (3.2.3), JBossCache(1.0.2).

JBossCache is wrapped around a home made MatrixCache that implments net.sf.hibernate.cache.Cache
and, basically, delegates incoming calls to an instance of JBossCache.

The JBossCache mode is LOCAL and isolation level is REPEATABLE_READ.

I have tried to cache queries. But I encountered the following problem:

After a table is updated, the MatrixCache.put() is first called to invalidate the table (thus,
JBossCache.put() is called).

Then after the session is close, and the transaction commited, Hibernate calls MatrixCache.put() again.
At this time, JBossCache complains because the transaction is already commited. It does not send an exception.

Here is the log I get:

14:11:13,651 ERROR [TreeCache] getCurrentTransaction(): registration with transaction failed
java.lang.IllegalStateException: Already committed.
at org.jboss.tm.TransactionImpl.registerSynchronization(TransactionImpl.java:687)
at org.jboss.cache.TreeCache.getCurrentTransaction(TreeCache.java:2592)
at org.jboss.cache.TreeCache.put(TreeCache.java:1329)
at org.jboss.cache.TreeCache.put(TreeCache.java:1314)
at com.protonworld.cia.cache.MatrixCache.put(MatrixCache.java:147)
at net.sf.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:46)
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:578)
at net.sf.hibernate.engine.CacheSynchronization.afterCompletion(CacheSynchronization.java:29)
at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1342)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:419)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:277)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:700)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:367)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)


After that failure, every attempt to modify the same table fails. It seems that the JBossCache still holds a write lock.

Here is the stack trace after the second update

14:12:00,605 ERROR [IdentityLock] IdentityLock.acquireWriteLock(): lock could not be acquired after 10000 ms. Lock map ownership Read lock owners: []
Write lock owner: <null>:4

14:12:03,323 ERROR [SessionImpl] Could not synchronize database state with session
net.sf.hibernate.cache.CacheException: org.jboss.cache.lock.TimeoutException: IdentityLock.acquireWriteLock(): lock could not be acquired after 10000 ms. Lock map ownership Read lock owners: []
Write lock owner: <null>:4

at com.protonworld.cia.cache.MatrixCache.put(MatrixCache.java:155)
at net.sf.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:41)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2307)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2262)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2187)
at com.protonworld.cia.bo.persobureau.PersoBureauManagerEJB.setPersoBureauDetails(PersoBureauManagerEJB.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:700)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:367)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)



Has anybody met a similar problem?


Thank you.

J-C Mincke

I'm also am getting both these errors. The write lock problem I posted to the JBossCache forum and they requested a debug trace. I found that using Hibernate 2.1.4, JBoss 3.2.4 and using the JBossCache that was distributed with that release the locking problem went away. I also changed from REPEATABLE_READ to NONE as well, so you might try that.

As for the getCurrentTransaction() failure, I'm also getting that error and I cannot figure out why. It seems if I don't deploy the treecache.xml file, that error goes away. I also posted the error on the JBossCache forum hoping someone knows what is causing this error.


Rich

You must use the transactional concurrency strategy with JBossCache.

But as soon as I use REPEATABLE_READ, I have the cache locking issue everytime as shown above. Any ideas why?

>I also changed from REPEATABLE_READ to NONE as well.

In that case, JBossCache does not use locking but it is not what I want.

>As for the getCurrentTransaction() failure...

Debugging Hibernate shows that it calls JBossCache.put() after the transaction is commited.
So I guess the the cache has good reasons to complain. However it seems that JBossCache acquires
a write lock at that time and does not release it (in fact it never release it).

I do not understand why Hibernate does such a call with a commited transaction... or I am completely missing something.

The workaround I am using now is a bit ugly - but it masks the symtoms. There is a home made MatrixCache wrapped around JBossCache.
In MatrixCache.put() I check whether the transaction is active before calling JbossCache.put().

I hope a better solution exists.

J-C

>I do not understand why Hibernate does such a call with a commited transaction... or I am completely missing something.

Could someone on the Hibernate Development Team explain why or this a bug?

Thanks in advance,

Rich

Oh, you never explained that this is with the query cache. You will need to put the JBoss query cache region in some kind of nonstransactional mode. Not sure how to do this, ask Ben Wang.

Gavin and I just discussed over IM. Basically, JBossCache's transaction is per cache instance. So to use query cache without transaction, the best option is perhaps to create two separate cache instances. I don't know whether this meets the need though.

Regards,

-Ben Wang

Now I'm confused. I thought I could just select the TreeCache in place of the ehache and instantly get a transactional cache. Is that not the case? The Hibernate documentation seems to read that way. If that isn't the case, how else can I get a transactional cache for read/write/updates/deletes using Hibernate that I can run within a JBoss CMT.

Thanks,

Rich

No, the Hibernate documentation is quiet clear that JBossCache only supports the transactional concurrency strategy. It is not just a simple property file change.

In addition, it looks like we might have some extra little wrinkles to get the query cache to work with JBossCache. I'm talking to Ben about this.

Hello all,

>Gavin and I just discussed over IM. Basically, JBossCache's transaction is per cache instance. So to use query cache without transaction, the best option is perhaps to create two separate cache instances. I don't know whether this meets the need though.

I have now 2 jboss cache instances : one transactional for entities and the other for queries/time stamps. As far as Hibernate is concerned it works fine. But, damnation, now the transactional instance of JbossCache throws a null pointer exception when trying to acquire a lock().

I'll keep you informed.

Regards.

J-C

>I have now 2 jboss cache instances : one transactional for entities and the other for >queries/time stamps. As far as Hibernate is concerned it works fine. But, damnation, now >the transactional instance of JbossCache throws a null pointer exception when trying to >acquire a lock().

This might be a newbie question, but I'm not following the "two cache" solution. I'm not using the query cache (I have not enabled it) so I'm not sure how that is involved in my problem. How do you even configure this (i.e. are you creating two session factories?).

In my case, I get the same error with the following scenario (running with a JBoss CMT):

1) The client Insert new objects in a transaction using saveOrCopyUpdate than a session.flush(). Works fine object is inserted

2) The same client (In different transaction) comes by later to do an update, the server calls saveOrCopyUpdate(), appears to be no problem, but than session.flush() throws the write lock exception.

How is having a second cache instance going to solve this problem? Gavin you mentioned that "wrinkles" exist in Hibernates use of JBossCache. Are you talking Hibernate using the JBossCache for the query cache or the second level cache? I'm assuming that if I have the query cache disabled, it isn't involved in my case (unless something is going on within Hibernate that I'm not aware of).

Sorry for posting a newbie question here, but I'm trying to understand what is broken and the current workaround.

Thanks,

Rich

afaict, it looks like a SessionFactory has a single CacheProvider. how were you able to get hibernate to see and use the two separate caches (one transactional and one not) from the one CacheProvider? custom cache provider?

thanks.

-l