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
stmt.addBatch();
} // while (tracks in batch)
stmt.executeBatch();
conn.commit();
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.
thanks,
Bogdan.
On 8/1/07, Bryan Pendleton <[EMAIL PROTECTED]> 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
>
>
