db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-5137) Enable or remove Derby3980DeadlockTest
Date Wed, 16 Mar 2011 13:25:29 GMT

    [ 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

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:
>            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
> This this test should be enabled or removed if it adds no additional coverage. 
> Derby3980DeadlockTest  does seem to have some testing for  extendedDiagSeverity level
> 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

View raw message