db-derby-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-4193:
----------------------------------


I believe your proposed change may result in a change in behavior for isolation levels which
don't 
require previous key locking.  In particular if you use previous key locking code it may not
get a lock
at all for some isolation levels.  I am not sure how important it is, but the difference I
think is:
current code: It loops using the "fast" search until it can get a lock on the last row in
the last leaf page while holding latch and not waiting on lock.
change:  in some isolation levels may not get lock in the position code, and instead will
fail to get lock
                 in fetchMax() code and give up earlier on the "fast" search in case where
there is competition
                 for the lock.

Reading through the comments in the code, I believe they are misleading.  I think they came
from a
cut/paste of some prototype backward scan code and actually don't apply to the specific max
scan case.

> 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
>            Assignee: Knut Anders Hatlen
>         Attachments: d4193-1a.diff, 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