db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert J. Carr" <rjc...@gmail.com>
Subject Re: locking problem
Date Sat, 04 Jul 2009 21:55:00 GMT
Thanks Knut ... that's the exact sort of thing I was looking for.
I'll test it next week and post a follow-up then.

On Sat, Jul 4, 2009 at 12:04 PM, Knut Anders Hatlen<Knut.Hatlen@sun.com> wrote:
> "Robert J. Carr" <rjcarr@gmail.com> writes:
>
>> Hi Jeff-
>>
>> It initially happened in 10.3.2.1, but I just updated to 10.5.1.1 and
>> the same problem exists.
>>
>> And I may have mentioned in the original post it was a table lock, and
>> I don't know if I misread it initially or if something changed when I
>> updated derby, but it seems to be a row lock.  Here's a condensed
>> version of the lock trace:
>>
>> java.sql.SQLException: A lock could not be obtained within the time
>> requested.  The lockTable dump is:
>> XID       |TYPE   |MODE |LOCKCOUNT |LOCKNAME   |STATE |TABLENAME
>> ----------------------------------------------------------------
>> *** The following row is the victim ***
>> 5222      |ROW    |X    |0         |(2,38)     |WAIT  |SG_TRACKS
>> *** The above row is the victim ***
>> 5104      |ROW    |S    |1         |(2,38)     |GRANT |SG_TRACKS
>> 5104      |TABLE  |IS   |1         |Tablelock  |GRANT |SG_TRACKS
>> 5222      |TABLE  |IX   |2         |Tablelock  |GRANT |SG_TRACKS
>> ----------------------------------------------------------------
>
> If you run with derby.language.logStatementText=true you'll be able to
> find in derby.log which statements a transaction with a particular XID
> has executed. This may help you track down the runaway transaction
> that's holding onto the shared row lock.
>
> --
> Knut Anders
>

Mime
View raw message