[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969019#action_12969019
]
Dag H. Wanvik edited comment on DERBY-4741 at 12/7/10 4:41 PM:
---------------------------------------------------------------
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[0].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 ;-)
was (Author: dagw):
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.
