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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2008/07/23 12:53:31 UTC
[jira] Commented: (DERBY-3757) 'ASSERT FAILED transaction table has
null entry when running new StressMultiTest
[ https://issues.apache.org/jira/browse/DERBY-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615950#action_12615950 ]
Knut Anders Hatlen commented on DERBY-3757:
-------------------------------------------
It looks to me as if the rest of the class actually uses synchronization on "this" when entries are added to or removed from the hash table. The exception is if it happens during recovery (which is single-threaded and therefore OK), but it also looks like there's a code path from Xact.close() -> XactFactory.remove() -> Xact.remove() -> Hashtable.remove() that is not synchronized on "this" and which is likely causing the assert failure by removing an entry while another thread is iterating over the table.
Although this failure is seen in debug code, I think it indicates that the synchronization scheme used in TransactionTable is flawed, so I would feel more comfortable if we fixed the synchronization. I have tried to understand how the synchronization in this class is supposed to work before, but with no success.
What I have problem understanding, is when to synchronize on which object. The class javadoc says that the class depends on Hashtable synchronization, but says nothing about synchronization on "this". Some of the methods explicitly synchronize on "this", others on "trans", some rely on the implicit synchronization from the Hashtable class, and some have a synchronized (this) block enclosing a synchronized (trans) block. Some of the code even says that we need synchronization on "this" here without synchronizing on "this".
> 'ASSERT FAILED transaction table has null entry when running new StressMultiTest
> --------------------------------------------------------------------------------
>
> Key: DERBY-3757
> URL: https://issues.apache.org/jira/browse/DERBY-3757
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.0.0
> Environment: Windows XP
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201 (SR4))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20070201 (JIT enabled)
> J9VM - 20070131_11312_lHdSMR
> JIT - 20070109_1805ifx1_r8
> GC - 200701_09)
> JCL - 20070131
> Reporter: Kathey Marsden
>
> When trying the DERBY-1764-V2.diff patch of DERBY-1764, I got this assertion running the test. It appears to be a bug iin Derby.
> 1) testStressMulti(org.apache.derbyTesting.functionTests.tests.multi.StressMultiTest)java.sql.SQLException: Java exception: 'ASSERT FAILED transaction table has null entry: org.apache.derby.shared.common.sanity.AssertFailure'.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87)
> at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2183)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1325)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:625)
> at <unknown class>.<unknown method>(Unknown Source)
> at org.apache.derbyTesting.functionTests.tests.multi.StressMultiTest$StressMultiRunnable.run(StressMultiTest.jav
> a:317)
> at java.lang.Thread.run(Thread.java:803)
> Caused by: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED transaction table has null entry
> at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> at org.apache.derby.impl.store.raw.xact.TransactionTable.getTransactionInfo(TransactionTable.java:968)
> at org.apache.derby.impl.store.raw.xact.XactFactory.getTransactionInfo(XactFactory.java:991)
> at org.apache.derby.impl.store.raw.RawStore.getTransactionInfo(RawStore.java:1153)
> at org.apache.derby.impl.store.access.RAMAccessManager.getTransactionInfo(RAMAccessManager.java:912)
> at org.apache.derby.impl.services.locks.Deadlock.buildException(Deadlock.java:266)
> at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:613)
> at org.apache.derby.impl.services.locks.AbstractPool.lockObject(AbstractPool.java:117)
> at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(RowLocking3.java:248)
> at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:504)
> at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:335)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:628)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:112)
> at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:304)
> at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(BTreeScan.java:1809)
> at org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:680)
> at org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(IndexRowToBaseRowResultSet.java:3
> 73)
> at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:255)
> at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:186)
> at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:424)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:246)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:384)
> 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.executeUpdate(EmbedStatement.java:175)
> at org.apache.derbyTesting.functionTests.tests.multi.StressMultiTest$StressMultiRunnable.update(StressMultiTest.
> java:471)
> ... 2 more
> FAILURES!!!
> Tests run: 3, Failures: 0, Errors: 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.