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

Kristian Waagan commented on DERBY-4741:
----------------------------------------

Thanks, Dag.

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

Not sure there is something to improve here, I guess this is a question about 
personal preference.
Explicit initialization of instance variables used to result in two assignments 
(first the default value for the type, and then the explicit value), which is 
kind of unnecessary if both assignments use the same value. I don't know if 
this is still the case.

And I have become quite accustomed to use the "Step over" or "Run to cursor" in 
the debugger :)
Finally, if the initial value isn't the default for the data type, then you 
have to assign the correct value anyway - either in the constructor or as an 
instance variable initializer (i.e. private int i = 3).


Thanks for working on the interrupt issue! I think it is of great value for 
Derby to be able to handle interrupts better. This is especially important 
when/if other software products used together with Derby use Thread.interrupt() 
internally.

> 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-kristians-01.diff, 
> 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.

Reply via email to