[
https://issues.apache.org/jira/browse/DERBY-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4825:
--------------------------------------
Attachment: postcommit.diff
I found that the background thread obtains exclusive locks on rows the
SYSSTATEMENTS table while doing post-commit work, so I suspect that's what
making these locks turn up intermittently in the lock table.
The attached patch makes assertLockCount() wait for post-commit work to
complete before it counts the locks. On a machine where LargeDataLocksTest has
failed every time I've run it as part of suites.All, the entire test suite ran
cleanly with the patch. I'll rerun suites.All to verify that it wasn't just
pure luck that made it pass this one time. (I have never seen the failure
outside of suites.All, so I don't have any quicker way to verify it.)
If we make this change, I don't think we should move assertLockCount() to
BaseJDBCTestCase just yet since it now depends on a stored procedure that won't
be available in general.
> Assert failure in LargeDataLocksTest.testGetCharacterStream() because of
> wrong number of locks
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-4825
> URL: https://issues.apache.org/jira/browse/DERBY-4825
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.6.2.1
> Environment: FreeBSD 8.1, i386
> Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: dump-locks.diff, postcommit.diff
>
>
> I saw this failure when running suites.All on the 10.6.2.1 release candidate:
> 1)
> testGetCharacterStream(org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest)junit.framework.AssertionFailedError:
> expected:<0> but was:<3>
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest.testGetCharacterStream(LargeDataLocksTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> The assertion expects the lock table to have zero locks, but it finds three.
> The test succeeded when I later ran it 100 times outside of suites.All.
> The failure looks similar to DERBY-4301, but I saw this in a pure 10.6
> environment, whereas DERBY-4301 happened in a mixed 10.3/10.5 environment.
> Also, DERBY-4301 is consistently reproducible, whereas this failure appears
> to be intermittent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
