|
Hi everyone, We’re
having a problem in a system that’s in production using castor JDO. We are getting the following exception intermittently: org.exolab.castor.jdo.LockNotGrantedException:
persist.deadlock at org.exolab.castor.persist.ObjectLock.detectDeadlock(Unknown
Source) at org.exolab.castor.persist.ObjectLock.upgrade(Unknown
Source) at org.exolab.castor.persist.LockEngine$TypeInfo.upgrade(Unknown
Source) at org.exolab.castor.persist.LockEngine$TypeInfo.access$600(Unknown
Source) at org.exolab.castor.persist.LockEngine.writeLock(Unknown
Source) at org.exolab.castor.persist.TransactionContext.writeLock(Unknown
Source) at org.exolab.castor.persist.ClassMolder.preStore(Unknown
Source) at org.exolab.castor.persist.LockEngine.preStore(Unknown
Source) at org.exolab.castor.persist.TransactionContext.prepare(Unknown
Source) at org.exolab.castor.jdo.engine.DatabaseImpl.commit(Unknown
Source) at org.alt60m.persistence.castor.ObjectBroker.commit(Unknown
Source) at org.alt60m.hr.ms.servlet.MSInfo.saveObjectHash(Unknown
Source) at org.alt60m.hr.ms.servlet.MSController.appFormSave(Unknown
Source) at java.lang.reflect.Method.invoke(Native
Method) at org.alt60m.servlet.Controller.processRequest(Unknown
Source) at org.alt60m.servlet.Controller.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at I was reading about bug 1127 in bugzilla
(http://bugzilla.exolab.org/show_bug.cgi?id=1127)
and apparently we may be having the same sort of issue… Here’s my question, tho: The problem occurs only intermittently and we cannot
reproduce it reliably. I guess what
is happening is castor is getting a readLock on the record
somewhere (we’re using SQL Server 2000 with ms jdbc
drivers)… and
then somehow, that readLock is never getting released. Either due to some exception occurring or
*something* that keeps the read
lock… Subsequent accesses to
that record fail with the exception above until tomcat is restarted. My question is this:
Once you’re outside of the transaction, what conditions would
cause castor to keep the readlock (or writelock) open?
If you had a db.begin() and then some exception without a finally or whatever
that didn’t do any kind of db.rollback/commit,
is it possible castor would hold open the record lock? This is killing us because we can’t
reproduce it reliably, but it pops up every day or so on our production system
and we have to restart tomcat in order to clear the lock… Any thoughts? Thanks so much for all of your volunteered time! Ken. |
