db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <ron...@innovation.ch>
Subject Re: disabling locking
Date Mon, 06 Apr 2009 03:56:54 GMT
On Thu, Apr 02, 2009 at 05:35:48PM +0200, Knut Anders Hatlen wrote:
> "Life is hard, and then you die" <ronald@innovation.ch> writes:
> 
> > On Thu, Apr 02, 2009 at 02:08:31AM +0200, Dag H. Wanvik wrote:
> >> "Life is hard, and then you die" <ronald@innovation.ch> 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


Mime
View raw message