Re: locking problem

> "Robert J. Carr" <rjcarr@...> 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
>