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 Thu, 02 Apr 2009 13:12:22 GMT
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)
    at org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(Unknown
Source)
    at org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(Unknown
Source)
    at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown Source)
    at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(Unknown Source)
    at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
    at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(Unknown
Source)
    at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.getRowFromResultSet(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.getNextRowFromRS(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
    at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
    at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
    - locked <0x00002aaae9a05158> (a org.apache.derby.impl.jdbc.EmbedConnection40)
    at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
    at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source)
    at org.apache.derby.iapi.jdbc.BrokeredPreparedStatement.executeQuery(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?


  Cheers,

  Ronald


Mime
View raw message