Werner,
I'm using Oracle 9.2. Sorry, I didn't make it clear enough in my
original mail. The existing code currently creates a JDO instance per
request and I am re-working it to put the JDO instance in the
ServletContext or similar.
I was just hoping that I might get some hints as to what else I should
be looking for when I get to that point, but I'm also happy to get
there, measure the effect and then see what new information I can
provide about this problem.
Cheers,
James
Werner Guttmann wrote:
James,
what RDBMS are you using ? And with regards to your last question, let
me just add that you should not create new JDO instances (or JDOManager
instances, as they are named with more recent releases) in a
multi-threaded, heavy-load application.
Just create a JDO instance once, and then call JDO.getDatabase()
whenever you've got something to do against the database, e.g. pesist an
entity, load an entity, etc.
Werner
James Abley wrote:
Hi,
I am having some problems with deadlocks in my application. It works
fine with a single client and I have functional tests which exercise
this part of the application, but once I start cranking up the number of
clients, I rapidly see lots of these:
Caused by: org.exolab.castor.jdo.TransactionAbortedException: Nested
error: org.exolab.castor.jdo.LockNotGrantedException: Deadlock has been
detected while attempting to acquire a lock: Deadlock has been detected
while attempting to acquire a lock
at
org.exolab.castor.persist.TransactionContext.prepare(TransactionContext.java:1654)
at
org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java:545)
vola ... 34 more
Caused by: org.exolab.castor.jdo.LockNotGrantedException: Deadlock has
been detected while attempting to acquire a lock
at
org.exolab.castor.persist.ObjectLock.detectDeadlock(ObjectLock.java:983)
at
org.exolab.castor.persist.ObjectLock.upgrade(ObjectLock.java:770)
at
org.exolab.castor.persist.LockEngine$TypeInfo.upgrade(LockEngine.java:1324)
at
org.exolab.castor.persist.LockEngine$TypeInfo.access$600(LockEngine.java:1055)
at
org.exolab.castor.persist.LockEngine.writeLock(LockEngine.java:801)
at
org.exolab.castor.persist.TransactionContext.writeLock(TransactionContext.java:1344)
at
org.exolab.castor.persist.ClassMolder.preStore(ClassMolder.java:1547)
at
org.exolab.castor.persist.LockEngine.preStore(LockEngine.java:718)
at
org.exolab.castor.persist.TransactionContext.prepare(TransactionContext.java:1521)
... 36 more
I am using Castor 0.9.6. I tried upgrading to 1.0.3 but got
NullPointerExceptions (I'll create a test case separately to see if it's
a bug, or more probably, a problem with my mapping file), so I'm
sticking with 0.9.6 currently and trying to understand how I'm misusing
Castor and what I should do to eliminate, or at least minimise these
deadlocks.
The only related thread that I have found so far on the mailing list
archive is this:
http://www.mail-archive.com/[email protected]/msg00205.html
There are a couple of the suggested issues present in the codebase that
I am currently working on fixing; notably a new JDO instance is being
created each request:
JDO newJdo = new JDO();
newJdo.setDatabaseName(databaseName);
// We resolve the full config URI
URL u = getClass().getResource(configurationURI);
if (u == null) {
throw new RepositoryException(
"Unable to locate config file " + configurationURI);
}
newJdo.setConfiguration(u.toString());
But I was wondering if people might be able to comment on any other
fruitful avenues to pursue?
Regards,
James
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
