[jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

    [ 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