[
https://issues.apache.org/jira/browse/DERBY-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007459#comment-13007459
]
Knut Anders Hatlen commented on DERBY-5137:
-------------------------------------------
Sorry, I didn't notice that there already was a test for the issue when I
checked in the fix for DERBY-3980.
Apart from the security manager magic, the test case looks more or less
identical to the one checked in together with the fix, and enabling it wouldn't
add any coverage. I don't understand what's achieved by using a custom security
policy in that test. If it's meant for testing extendedDiagSeverity and/or
security managers, it would probably be better to move that part into a test
dedicated to that purpose, and also adding some comments explaining what's
being tested.
If we enable the test, we should probably add some more synchronization between
the two threads. Currently, the test doesn't ensure that both threads have
performed the select query before they perform the delete. I think this means
that it's possible that one of the threads has performed both the select and
the delete before the other thread has done the select, and then we may see
intermittent test failures because there is no deadlock. But since the test
scenario is so similar to the one in DeadlockDetectionTest, it's probably fine
just to remove this test.
> Enable or remove Derby3980DeadlockTest
> --------------------------------------
>
> Key: DERBY-5137
> URL: https://issues.apache.org/jira/browse/DERBY-5137
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.8.0.0
> Reporter: Kathey Marsden
>
> As part of early work on DERBY-3980, I checked in an unrun test for this
> issue when I was working on it a long time ago, Derby3980DeadlockTest.
> I verified it does pass now but maybe the new DeadLockDetectionTest provides
> the same coverage.
> This this test should be enabled or removed if it adds no additional
> coverage.
> Derby3980DeadlockTest does seem to have some testing for
> extendedDiagSeverity level and
> diagProperties.setProperty("derby.stream.error.extendedDiagSeverityLevel",
> "30000");
> One thing to note is that it now, with the IBM JVM, I think correctly will
> print
> JVMDUMP010I Java dump written to ...
> I am surprised though not to see a thread dump in derby.log, so maybe there
> is an issue with extendedDiagSeverity that needs to be looked at too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
