db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Tue, 07 Dec 2010 21:41:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969019#action_12969019
] 

Dag H. Wanvik commented on DERBY-4741:
--------------------------------------

Thanks for looking at the new code, Kristian, I'll make a new patch to cater for your comments.

> o in writeFull the variables beforeOpen and beforeInterrupt are unused. Can they be removed?
>  o the same issue in readFull.

Absolutely, debugging cruft. Thanks for spotting those.

>  o would it make sense to make the monitor object channelCleanupMonitor final?

Absolutely.

>  o redundant call to Thread.currentThread when invoking holdsLock.

Thanks, thought I had cleaned out those, but there were two left!

>  o missing JavaDoc for recoverContainerAfterInterrupt

Added Javadoc for recoverContainerAfterInterrupt and awaitRestoreChannel.

> A more theoretical question at the end.  Is there a reason to
> explicitly define instance variables with the default value for the
> data type?  I.e., int i = 0, boolean b = false.

No. I tend to often use explicit initialization due to my paranoid
streak I guess. I see the data flow analysis barks if you use a local
variable uninitialized, although not for a class member, not clear to
me why Java differentiates here.

public class Foo {
    public boolean bb;

    public static void main(String[] args) {
        boolean b;

        if (args.length > 0 && args[1].equals("foo")) {
            b = true;
        }

        if (b) { // compiler barks
            System.err.println("b is true"); 
        }

        Foo f = new Foo();
        if (f.bb) { // OK
            System.err.println("bb is true");
        }

    }
}

I guess I have tended to treat them the same. I'll try to improve ;-)




> Make Derby work reliably in the presence of thread interrupts
> -------------------------------------------------------------
>
>                 Key: DERBY-4741
>                 URL: https://issues.apache.org/jira/browse/DERBY-4741
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4741-a-01-api-interruptstatus.diff, derby-4741-a-01-api-interruptstatus.stat,
derby-4741-a-02-api-interruptstatus.diff, derby-4741-a-02-api-interruptstatus.stat, derby-4741-a-03-api-interruptstatus.diff,
derby-4741-a-03-api-interruptstatus.stat, derby-4741-a-04-api-interruptstatus.diff, derby-4741-a-04-api-interruptstatus.stat,
derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat, derby-4741-b-01-nio.diff,
derby-4741-b-01-nio.stat, derby-4741-b-02-nio.diff, derby-4741-b-02-nio.stat, derby-4741-b-03-nio.diff,
derby-4741-b-03-nio.stat, derby-4741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff,
derby-4741-c-01-nio.stat, derby-4741-nio-container+log+waits+locks+throws.diff, derby-4741-nio-container+log+waits+locks+throws.stat,
derby-4741-nio-container+log+waits+locks-2.diff, derby-4741-nio-container+log+waits+locks-2.stat,
derby-4741-nio-container+log+waits+locks.diff, derby-4741-nio-container+log+waits+locks.stat,
derby-4741-nio-container+log+waits.diff, derby-4741-nio-container+log+waits.stat, derby-4741-nio-container+log.diff,
derby-4741-nio-container+log.stat, derby-4741-nio-container-2.diff, derby-4741-nio-container-2.log,
derby-4741-nio-container-2.stat, derby-4741-nio-container-2b.diff, derby-4741-nio-container-2b.stat,
derby.log, derby.log, InterruptResilienceTest.java, MicroAPITest.java, xsbt0.log.gz
>
>
> When not executing on a small device VM, Derby has been using the Java NIO classes java.nio.clannel.*
for file io.
> If thread is interrupted while executing blocking IO operations in NIO, the ClosedByInterruptException
will get thrown. Unfortunately, Derby isn't current architected to retry and complete such
operations (before passing on the interrupt), so the Derby database can be left in an inconsistent
state and we therefore have to return a database level error. This means the applications
can no longer access the database without a shutdown and reboot including a recovery.
> It would be nice if Derby could somehow detect and finish IO operations underway when
thread interrupts happen before passing the exception on to the application. Derby embedded
is sometimes embedded in applications that use Thread.interrupt to stop threads.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message