Hi all,
I previously posted a question on the user list [1]. Thanks to the
people who responded to my original post. I have made the recommended
changes and look forward to upgrading to 1.0.6 in the near future [2].
This was supposed to be a post to the dev list, but I'm having problems
subscribing and Werner thought it would be OK to post here for now.
I am still getting deadlocks in my application. My understanding is that
this is by design - the only way I have been able to replicate the
problem in isolation is by having multiple clients loading the
application and trying to update what equates to the same record in the
a given table at the same time. This causes a deadlock to be detected
and one of the clients is chosen as the victim and receives an
Exception. That seems like reasonable behaviour to me. However, I would
like to confirm that the situation that I have created in my functional
test case for my application matches the situation that a customer is
seeing. I would like to add more information around the failure here -
currently, it only creates a LockNotGrantedException with a simple cause
string.
in ObjectLock.detectDeadlock:
throw new LockNotGrantedException(Messages.message("persist.deadlock"));
I would like to enhance this to note the object that the attempt to lock
fails on, and potentially other useful information; e.g. what else has
the lock.
Anyone got any pointers on this area of the code, and what information
might be useful? I was intending on adding at least the
ObjectLock.toString() which contains the OID and the lock type (R/W),
but it might also be good to log things about the number of locks
examined? I'm not too clear on what some of the different objects
contain and thus what would be useful information to capture at the
point of failure. I'd also like if possible to write some (LearningTest)
test cases which capture knowledge about this part of the system and
confirm my understanding about what it's doing but I'm not sure how easy
that will be - initial reading of the code and sketching makes it seem
quite difficult to test in isolation.
I wrote the above yesterday - having spent some time trying to create
tests around this, it _is_ hard to get something in place, at least how
I intended for the tests to read. Either major refactoring or use of
reflection would be required judging by my initial exploration, and I'm
not sure I currently have the familiarity with the codebase to proceed
with that.
I was hoping to be able to do something like:
public void testWriteIsolationLevels() throws Exception {
clientA.getObjectLock(myDomainObject);
clientA.doStuff(myDomainObject)
try {
clientB.getObjectLock(myDomainObject);
fail("Deadlock should have been detected");
} catch (LockNotGrantedException expected) {
// ignore
} finally {
// tests should be isolated - ensure that no locks are retained
clientA.rollback(myDomainObject);
}
}
public void testSequentialWritesAreOK() throws Exception {
clientA.getObjectLock(myDomainObject);
clientA.doStuff(myDomainObject);
clientA.commit(myDomainObject);
clientB.getObjectLock(myDomainObject);
clientB.doStuff(myDomainObject);
clientB.commit(myDomainObject);
}
Oh well, it was a nice idea! Am I missing some existing tests that are
at this level?
Presumably there are also functional tests within Castor around this
area which I haven't discovered yet?
Cheers,
James
[1] http://archive.castor.codehaus.org/user/454A0F3F.8060003%40volantis.com
[2] http://jira.codehaus.org/browse/CASTOR-1688
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
