db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J.Engl...@bton.ac.uk
Subject Re: Locking problem
Date Wed, 13 Oct 2010 11:44:40 GMT
Bryan Pendleton wrote:
> 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
> transaction.

Thanks. I've been analysing my code and have found a couple of places
where I didn't have a finally block; I've changed them, but I'm still
puzzled -- the single transaction thing bothers me since I can't find
anywhere doing multiple updates to the users table, and I can't see
why it should have tried to update all 417 rows even if autocommit
was turned off and it was updating one at a time. Oh well, my problem,
not yours.

> 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.

Thanks, I'll try that (and wait for it to happen again, of course...
I hate timing-dependent errors).

> 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.

When I get more information about the problem, I may well do that!

Thanks again for all your advice,

  John English              | mailto:je@brighton.ac.uk
  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
  School of Computing & MIS | "Those who don't know their history
  University of Brighton    |  are condemned to relive it" (Santayana)

This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/

View raw message