[
https://issues.apache.org/jira/browse/DERBY-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483358#comment-13483358
]
Knut Anders Hatlen commented on DERBY-4323:
-------------------------------------------
I saw this now with Java SE Embedded 7 running on a 720MHz ARM processor
(timing issues are to be expected, as suites.All takes 14 hours to complete on
this platform).
I think it should be possible to reduce the risk of these timing problems
without increasing the deadlock timeout. For example, we could compile both of
the SELECT statements that we set up for deadlock, before we execute them. This
way, the time it takes to compile the queries doesn't eat up parts of the
two-second time slot we have available for getting the statements to execute
and reach the point where they lock the row. I'll give it a try.
> test failure in lang.ErrorMessageTest with IBM iseries IBM 1.5
> --------------------------------------------------------------
>
> Key: DERBY-4323
> URL: https://issues.apache.org/jira/browse/DERBY-4323
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.5.2.0
> Environment: IBM iseries, OS: AS/400; OS version: V5R4M0, IBM 1.5
> (1.5.0_13-b05)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Labels: derby_triage10_8
> Attachments: ErrorMessageTest_derby.log, error-stacktrace.out
>
>
> There was this error during the 10.5.2.0 test run - when the ErrorMessageTest
> was run by itself later there was no problem, and neither did this show up
> during the ibm 1.6 run:
> 1)
> testDeadlockTimeout(org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest)junit.framework.ComparisonFailure:
> Not a deadlock expected:<...001> but was:<...XL2>
--
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
