No, we don't have any clues whatsoever. We already spent quite a lot of time
trying to find the reason ourselves, but with no luck. Most of these errors
appear what seems completely at random after a longer period of application run
time. The only clue that might help is perhaps that if we use pessimistic
locking, we are getting errors like this:
2006-05-22 12:15:22,520 ERROR [org.jboss.cache.lock.IdentityLock] write lock
for /org/hibernate/cache/UpdateTimestampsCache/TASK_INSTANCE_PARAM could not be
acquired after 0 ms. Locks: Read lock owners: {}
| Write lock owner: GlobalTransaction:<192.168.170.170:50108>:1458
| (caller=GlobalTransaction:<192.168.170.170:50108>:1457, lock info: write
owner=GlobalTransaction:<192.168.170.170:50108>:1458 (activeReaders=0,
activeWriter=Thread[TP-Processor1,5,jboss], waitingReaders=0, waitingWriters=0,
waitingUpgrader=0))
| 2006-05-22 12:15:22,520 INFO [org.jboss.cache.interceptors.TxInterceptor]
There was a problem handling this request
| org.jboss.cache.lock.TimeoutException: write lock for
/org/hibernate/cache/UpdateTimestampsCache/TASK_INSTANCE_PARAM could not be
acquired after 0 ms. Locks: Read lock owners: {}
| Write lock owner: GlobalTransaction:<192.168.170.170:50108>:1458
| (caller=GlobalTransaction:<192.168.170.170:50108>:1457, lock info: write
owner=GlobalTransaction:<192.168.170.170:50108>:1458 (activeReaders=0,
activeWriter=Thread[TP-Processor1,5,jboss], waitingReaders=0, waitingWriters=0,
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.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:199)
| at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:132)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
| at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
| 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.handleNonTxMethod(TxInterceptor.java:328)
| at
org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:139)
| 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:4804)
| at org.jboss.cache.TreeCache.putFailFast(TreeCache.java:3207)
| at org.hibernate.cache.TreeCache.put(TreeCache.java:74)
| at
org.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:54)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:244)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
| at
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
| at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
| at
org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:135)
"Lock could not be acquired after 0 ms." Our lock timeout is set appropriately
(and doesn't help if we increase it to infinity), in fact we are using the
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate.
These errors happen with frequency similar to that of the errors that we get
with optimistic locking, so there may be something in common. However, the
pessimistic locking errors, other than filling our logs, don't seem to cause
any problems in the application (which is strange). We've been getting them for
months - ever since switching from JDBC to JTA transactions, I think, and there
were no bug reports whatsoever. So this is the configuration we're using now,
but of course we don't like it this way. Getting rid of these errors was also
the main reason we wanted to switch to optimistic locking. However, the errors
we got with optimistic locking proved quite fatal, so we switched back to
pessimistic the same day.
I hope this gives you some ideas. There may be something wrong with our
Hibernate or Cache configuration, but that is unlikely, since we're not using
them in any unusual way. We already gave up on this, but if you have any ideas
how we could solve this together, we'll be happy to help.
Regards,
Jaka
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946271#3946271
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3946271
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
