db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Locking problem
Date Thu, 07 Oct 2010 01:44:31 GMT
> I normally leave autocommit turned on, but in a few places in my code I
> wrap multiquery transactions like this:
> try {
> setAutoCommit(false);
> ... // do a bunch of related updates
> }
> finally {
> commit();
> setAutoCommit(true);
> }
> Is this the right way to do it, and would the behaviour I see have to be
> caused by a multi-query transaction of this sort (since the locks all
> have the same XID)? If so, it would narrow down the things I need to
> look at...

This seems like a reasonable approach to me.If you think you are somehow
accidentally leaving autocommit on-when-it-should-be-off, or vice versa,
you can sprinkle some Connection.getAutoCommit() calls around to verify
that the state is as you expect it to be.

And, yes, since the locks all have the same XID, it means that they were
all acquired without an intervening commit, so you should be analyzing
places in your program where you can process multiple rows in a single

If you can reproduce the behavior that is problematic, another nice tool
is to turn on derby.language.logStatementText (see this page:
http://db.apache.org/derby/docs/10.6/ref/rrefproper43517.html), as that
will place a lot of useful information into the derby.log file about what's
going on, and hopefully you can read the log "backwards" from the time of
the locking problem and then figure out what was leading up to the problem
that resulted in all those other locks being held.

If you have both derby.language.logStatementText and derby.locks.deadlockTrace
enabled, your derby.log file should contain a pretty complete picture of
the circumstances that led up to the problem.

If you can post some of that information (i.e., if it isn't too sensitive),
I'm sure others will be glad to help you interpret what you see there.



View raw message