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: disabling locking
Date Thu, 02 Apr 2009 15:35:48 GMT
"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]
>> >> Note: Knut mentioned that if the index is not unique, the
>> >> SELECT.. WHERE could qualify more than one row, so the index scan
>> >> might try to also lock the row *after* the first qualifying row, say one
>> >> whose value of version=4. If that row was just inserted, you could
>> >> still see a hang..
>> >
>> > Unfortunately the indexed columns are definitely not unique (well,
>> > sometimes they are, but during update activity they certainly aren't).
>> > I.e. in general yes, the selects will find several rows to be updated
>> > or deleted.
>> >
>> > So am I back to square one then? "Work mostly" is not an option...
>> 
>> Unless somebody has some other insights, maybe so. I would try to
>> verify this, though, maybe the base row isn't attempted locked in this
>> case (since the index row doesn't qualify) - I am not sure. Sorry if I
>> am a bit vague here, I don't know this part of the code too well.
>
> 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

-- 
Knut Anders

Mime
View raw message