db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Calmac" <bc4...@gmail.com>
Subject Re: lock escalation and deadlocks
Date Wed, 01 Aug 2007 16:43:28 GMT
Hi Bryan (sorry for the misspelling lat time),

The insert transaction is really simple (see below) so I am pretty
sure it doesn't do anything else else. In support of that, I want to
say that the deadlock trace does not reflect the LOCKCOUNT. There are
literally about 150 lines in the trace even though LOCKCOUNT=476.

Here is the code related one transaction of the insert thread (really
nothing fancy):

         while(j-- > 0) {
           stmt.setLong(1, agentSessionId);
           stmt.setInt(2, 1);
           // ... other param setters
         } // while (tracks in batch)

And I would like to come back to the main question: How would you read
the deadlock trace from my previous email (the 3rd in the thread)?
What do you think could be the misterious 3rd connection that causes
the deadlock?

I will also cleanup my unit test (which actually is a benchmark) and
post it on the list so that you can reproduce the bahaviour. It
happens consistently, so this should not be a problem.



On 8/1/07, Bryan Pendleton <bpendleton@amberpoint.com> wrote:
> > Oh, and one more observation. The IX table lock for the insert thread
> > mentions LOCKCOUNT=476. I can only infer the meaning of the column (so
> > this might perfectly normal), but the number of row locks of that
> > connection is about 150 (it could not exceed 200, the number of
> > inserts I do per transaction).
> It sounds like the insert thread is doing more work than you expect
> it to be doing. You could investigate this using the logStatementText
> property to figure out what actual SQL is getting executed for each
> transaction in your application:
> http://db.apache.org/derby/docs/10.2/tuning/rtunproper43517.html
> thanks,
> bryan

View raw message