db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4193) ASSERT FAILED Scan position already saved with multi-threaded insert/update/delete
Date Tue, 28 Apr 2009 12:38:30 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703624#action_12703624
] 

Knut Anders Hatlen commented on DERBY-4193:
-------------------------------------------

I think the assert is harmless, in the sense that nothing bad should happen in non-debug builds.
It basically indicates that the last time we saved the position of this scan, we didn't subsequently
use it to reposition the scan, so in this case I think it just means that we saved the position
unnecessarily.

The code that fails tries to save the position of a max scan because it has to wait in order
to obtain the lock on the rightmost row in an index. In this case it won't use the saved position
when it wakes up, instead it performs a new search from the root of the B-tree to find the
rightmost row again (which is possibly a different row now). In the repro, the max scan needs
to wait a second time to lock the rightmost row because a new row has become the rightmost
one, and it's still locked exclusively.

Since the locking of the last row is performed the same way as one would do previous key locking
(the comment above it actually says "backward scan initial positioning will request a previous
key lock for initial positioning"), I believe that it would be correct to replace the call
to lockScanRow() with a call to lockNonScanPreviousRow(). Previous key locking will not save
the position when it needs to wait, so the assert failure will go away, and the logic in BTreeMaxScan.positionAtStartPosition()
will also be simpler as it doesn't need to decrement/increment pos.current_slot before/after
the lock call.

I think there may be similar problems in

  BTreeScan.positionAtStartForForwardScan()
  BTreeScan.positionAtStartForBackwardScan()
  BTreeMaxScan.fetchMax()

> ASSERT FAILED Scan position already saved with multi-threaded insert/update/delete 
> -----------------------------------------------------------------------------------
>
>                 Key: DERBY-4193
>                 URL: https://issues.apache.org/jira/browse/DERBY-4193
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.1.1, 10.6.0.0
>         Environment: Windows XP, IBM 1.6 SR6, Sun  1.6.0_01-b06
>            Reporter: Kathey Marsden
>         Attachments: ScanPosSaved.java, ScanPosSaved.java
>
>
> The attached program ScanPosSaved.java produces the error below, fairly quickly.  
> The program has three threads, one doing inserts into a table with an identity column,
one updating the row with the maximum id, one deleting the row with the maximum id.
> To reproduce, run >java ScanPosSaved  and <ctrl> <c> out of the program
after you get the error.
> I saw this 10.5 and trunk sane builds but did not see it on 10.4.  With the insane build
of 10.5.1.1 (RC2) I did not see any symptoms right away, so don't know how serious an issue
this is for insane builds.
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Scan position already
saved
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> 	at org.apache.derby.impl.store.access.btree.BTreeScan.savePositionAndReleasePage(BTreeScan.java:2148)
> 	at org.apache.derby.impl.store.access.btree.BTreeScan.savePositionAndReleasePage(BTreeScan.java:2212)
> 	at org.apache.derby.impl.store.access.btree.BTreeRowPosition.saveMeAndReleasePage(BTreeRowPosition.java:128)
> 	at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:295)
> 	at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599)
> 	at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105)
> 	at org.apache.derby.impl.store.access.btree.BTreeMaxScan.positionAtStartPosition(BTreeMaxScan.java:347)
> 	at org.apache.derby.impl.store.access.btree.BTreeMaxScan.fetchMax(BTreeMaxScan.java:434)
> 	at org.apache.derby.impl.store.access.btree.index.B2I.fetchMaxOnBTree(B2I.java:739)
> 	at org.apache.derby.impl.store.access.RAMTransaction.fetchMaxOnBtree(RAMTransaction.java:1078)
> 	at org.apache.derby.impl.sql.execute.LastIndexKeyResultSet.openCore(LastIndexKeyResultSet.java:189)
> 	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
> 	at org.apache.derby.impl.sql.execute.ScalarAggregateResultSet.openCore(ScalarAggregateResultSet.java:133)
> 	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
> 	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:245)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:297)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:625)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:152)
> 	at ScanPosSaved.updateOperation(ScanPosSaved.java:62)
> 	at ScanPosSaved$3.run(ScanPosSaved.java:17)
> I discovered this when trying to get a smaller repro for DERBY-4181, but I think it is
a different issue, because it reproduces on multiple jvms and does not reproduce on 10.4.
 The assertion was added with DERBY-2991.  Knut could you perhaps assess how serious this
is?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message