"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
