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:j...@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/
___________________________________________________________
