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] Updated: (DERBY-4193) ASSERT FAILED Scan position already saved with multi-threaded insert/update/delete
Date Mon, 04 May 2009 12:47:30 GMT

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

Knut Anders Hatlen updated DERBY-4193:
--------------------------------------

    Attachment: d4193-1c.diff

Thanks, Mike. pos.init() should do the trick. In the 1c patch I've addressed the four cases
I identified as problematic the following way:

* BTreeMaxScan.positionAtStartPosition and BTreeScan.positionAtStartForForwardScan:
  - use pos.init() to clear the saved position

* BTreeScan.positionAtStartForBackwardScan:
  - this method is never used, as far as I can see, so I removed it instead of fixing it

* BTreeMaxScan.fetchMax:
  - not a problem in this method because it calls positionAtDoneScan() before it restarts
the scan from the beginning, so the position will be cleared in the code as it is now

I also added a test case for the forward scan case. Like the max scan test, it does not fail
consistently, but it fails in most cases in my environment without the fix.

The regression tests are running now.

> 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: btreemaxscancomments.diff, d4193-1a.diff, d4193-1b.diff, d4193-1c.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