You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2009/04/28 01:59:30 UTC
[jira] Created: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
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
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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4193:
----------------------------------
Attachment: ScanPosSaved.java
Correcting typo in previous repro. I was actually passing the same connection into two threads. The issue still reproduces with this corrected.
> 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.
[jira] Assigned: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reassigned DERBY-4193:
-----------------------------------------
Assignee: Knut Anders Hatlen
> 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: 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4193:
--------------------------------------
Derby Info: [Regression] (was: [Regression, Patch Available])
Fix Version/s: 10.6.0.0
Committed revision 772090.
I'll also back-port the fix to 10.5.
> 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
> Fix For: 10.6.0.0
>
> 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-4193:
----------------------------------
i prefer the use of lockScanRow, so your most recent suggestion seems better. The code already does some special case code on the btree position in the cases I think you are going after - I wonder
if there should just be new routine on BTreeRowPosition to clear the state if you are intending to
re-search the tree. maybe .init() does the job?
Would the following work (or something like it)?:
old btreemax code:
if (latch_released)
{
// lost latch on pos.current_leaf, search the tree again.
pos.current_leaf = null;
continue;
}
new?:
if (latch_released)
{
// lost latch on pos.current_leaf, search the tree again - will not use current position
pos.init();
continue;
}
> 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, 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4193:
----------------------------------
Attachment: ScanPosSaved.java
> 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
>
>
> 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.
[jira] Commented: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-4193:
----------------------------------
Attachment: btreemaxscancomments.diff
Here is an updated version of BTreeMaxScan.java I would like to check into the trunk, it just has comment changes. I believe this better describes the intent of the code. I believe the old comments about previous key locking did not apply to the max scan.
> 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, 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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-1a.diff
The attached patch adds a test case to IndexSplitDeadlockTest that fails most of the time (there is a race for a lock, so that it sometimes doesn't fail) with the assert failure reported by Kathey.
The patch also changes BTreeMaxScan.positionAtStartPosition() so that it uses lockNonScanPreviousRow() instead of lockScanRow(). This change makes both IndexSplitDeadlockTest and ScanPosSaved run without errors.
> 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.
[jira] Commented: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703761#action_12703761 ]
Kathey Marsden commented on DERBY-4193:
---------------------------------------
Thanks Knut for the quick fix. I ran the program for 2 hours with the patch and got no errors and checked consistency and it was fine.
> 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.
[jira] Resolved: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-4193.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.5.1.2
Merged to 10.5 and committed revision 772146.
> 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
> Fix For: 10.5.1.2, 10.6.0.0
>
> 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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-1b.diff
An alternative to using lockNonScan* methods for the problematic cases is to add a flag to lockScanRow() to state whether or not the position should be saved if the latch is released. See the attached patch.
I'll try to write some test cases that trigger the assert from the other methods mentioned above.
> 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, 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4193:
--------------------------------------
Derby Info: [Patch Available, Regression] (was: [Regression])
All regression tests passed.
> 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.
[jira] Commented: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704146#action_12704146 ]
Knut Anders Hatlen commented on DERBY-4193:
-------------------------------------------
The suggested changes to the comments look like improvements to me. +1 to commit.
(I noticed that you added a RESOLVE comment in some code that you don't think will ever be called. I came to the same conclusion when I wrote tests for DERBY-2991 and added a comment about it in IndexSplitDeadlockTest. So we should probably just remove that code.)
As to the changed behaviour, I haven't been able to see any. I tried a simple SELECT MAX(X) FROM T, and observed this both with and without the patch:
* read uncommitted: no locks obtained in position or in fetchMax (IS obtained before position)
* read committed: zero duration row lock on last row obtained *both* in position and fetchMax (and IS before position)
* repeatable read and serializable: no locks in position/fetchMax (already had S on table)
I think that whether or not previous key locking should be used, is determined by the lockScanRow() method as it decides whether it should call lockNonScanPreviousRow(), and it's not determined by lockNonScanPreviousRow() itself. So my understanding of the code is that if lockScanRow() would have obtained a lock, so will lockNonScanPreviousRow().
And isn't this lock really a range lock, like the previous key locks? It's not just protecting the row containing the max value, but really the range starting with that row, so that no higher values can be inserted while the lock is held.
> 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, 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-4193) ASSERT FAILED Scan position already
saved with multi-threaded insert/update/delete
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-4193:
---------------------------------
Issue & fix info: [High Value Fix]
> 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
> Fix For: 10.5.1.2, 10.6.0.0
>
> 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.