On Thu, Apr 02, 2009 at 05:35:48PM +0200, Knut Anders Hatlen wrote: > "Life is hard, and then you die" <[email protected]> writes: > > > On Thu, Apr 02, 2009 at 02:08:31AM +0200, Dag H. Wanvik wrote: > >> "Life is hard, and then you die" <[email protected]> writes: [snip] > > In doing more testing where I'm hitting the db with more queries in > > more threads, I've now run into the case where a simple SELECT is > > attempting to lock a row. So I'm really confused! Here is the stack > > trace from a thread-dump: > > > > - waiting on <0x00002aaae9a2a970> (a > > org.apache.derby.impl.services.locks.ActiveLock) > > at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(Unknown > > Source) > > - locked <0x00002aaae9a2a970> (a > > org.apache.derby.impl.services.locks.ActiveLock) > > at > > org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown > > Source) > > at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown > > Source) > > at > > org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(Unknown > > Source) > > at > > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(Unknown > > Source) > > at > > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockScan(Unknown > > Source) > > at > > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(Unknown > > Source) > > at > > org.apache.derby.impl.store.access.btree.index.B2IRowLocking1.lockScanRow(Unknown > > Source) > > [...] > > > The connection is definitely in READ_UNCOMMITTED mode (there are only > > two places where connections are created, and both look like > > > > XAConnection xaCon = dataSource.getXAConnection(); > > Connection con = xaCon.getConnection(); > > con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED); > > > > and the query in question is using the default concurrency and type > > (i.e. CONCUR_READ_ONLY and TYPE_FORWARD_ONLY). > > > > Why would a query in READ_UNCOMMITTED mode ever use RowLocking2? > > It looks like you're seeing the infamous scan protection lock, which has > caused some headaches for us. This lock has been removed in Derby 10.5 > (soon to be released). For more details, take a look at this bug report: > https://issues.apache.org/jira/browse/DERBY-2991
Thanks! I grabbed and built the latest code from the 10.5 branch, and indeed this seems to solve the issues, i.e. I can't reproduce any locking problems (unless I try to update the statistics with "CALL SYSCS_UTIL.SYSCS_UPDATE_STATISTICS(...)" - that quickly leads to deadlocks again - I'd probably need to run that while no other updates are happening). Cheers, Ronald
