db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: locking problem
Date Sat, 04 Jul 2009 19:04:42 GMT
"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