[
https://issues.apache.org/jira/browse/DERBY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765530#comment-13765530
]
Mike Matrigali commented on DERBY-5866:
---------------------------------------
definitely think knut's suggestion is worth looking into. Add printout of the
timestamp. A lot of the nightly's that are failing
are run on fast vmware machines now. And I believe timestamp is a known issue
with this kind of situation, where it is hard to
get the hardware timestamp to be updated as quickly for apps running on vmware
than you might expect from an app running directly
on the bare iron. We have seen similar issues with some tests that use to fail
where before and after timestamps for an operation
would return the same timestamp.
If this turns out to be the problem, ...
If upgrade were not an issue seems like fix would be to make the index unique
and handle a duplicate key error on insert, and retry
with timestamp+1. Depending on what kind of locks the ddl had for creating the
trigger, maybe you can first search for the timestamp
and then do insert if it does not exist in the non-unique index. Just need
enough locking to insure some other trigger create does
not sneak in.
>
> testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
> matching triggers need to be fired in order creation:1,NO CASCADE
> BEFORE,DELETE,ROW
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5866
> URL: https://issues.apache.org/jira/browse/DERBY-5866
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.1.1, 10.10.1.3
> Environment: Windows IBM 1.6 10.10.0.0 alpha - (1361856)
> Reporter: Kathey Marsden
> Assignee: Mamta A. Satoor
> Labels: derby_triage10_11
> Fix For: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0
>
> Attachments: error-stacktrace.out
>
>
> I saw this failure in the IBM nightlies on 7/15. The subsequent night did not
> fail, so appears intermittent
> http://cloudsoft.usca.ibm.com/intranet/nightlies/derbywinvm/JarResults.2012-07-15/ibm16_suites.All/suites.All.out
> 1)
> testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
> matching triggers need to be fired in order creation:1,NO CASCADE
> BEFORE,DELETE,ROW
> at
> org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.assertFiringOrder(TriggerTest.java:560)
> at
> org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testFiringConstraintOrder(TriggerTest.java:500)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
> at
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
> at
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
