db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lily Wei (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Tue, 12 Oct 2010 14:25:37 GMT

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

Lily Wei commented on DERBY-4741:

Hi Dag:
     Thank you. I am so exciting to help out testing and hope I can do more. Like Knut said,
mailjdbc interrupts on Browse.java and more detail on DERBY-3746 and DERBY-4166, the portion
of the code on Browse.java that call interrupt is: 
				//Checking whether Refresh thread is running after doing Browse work
				//If Refresh is not running, interrupt the thread
				if (ThreadUtils.isThreadRunning("Refresh Thread")) {
					MailJdbc.logAct.logMsg("******** Refresh is running");
				} else {
					Refresh th = (Refresh) ThreadUtils
							.getThread("Refresh Thread");
      Refresh thread and Brose thread are dealing with the same tables for mailjdbc application.
I am also reading Derby151Test to see whether we should simplify the mailjdbc test to better
fit testing this fix that will benefit a lot of customers. Thanks again. By the way, the read-only
error on Browse thread and  ArrayIndexOutOfBoundsException from backup thread is from running
mailjdbc with embedded server.

> 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:,,,,,,,,,,
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: 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, 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.

View raw message