Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <5797301.163911287158440234.JavaMail.jira@thor>
Date: Fri, 15 Oct 2010 12:00:40 -0400 (EDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4741) Make Derby work reliably in the
 presence of thread interrupts
In-Reply-To: <13345993.330341278959929752.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Hi Lily,

thanks again for looking at this :)

> However, I run mailjdbc again the latest
> derby-4741-nio-container+log+waits+locks+throws, the test run into
> Error ERROR 40001: A lock could not be obtained due to a
> deadlock. derby.log is attached for reference. 

Yes, I saw that such lock errors too after about 18 hours of so. I am
not yet sure they have anything to do with the patch changes, but I
can't rule it out. I don't know the test app well enough. If you have
any insight here which would indicate that locks should not occur
under normal operation, what would that be?  We could try to run the
patch without the changes I made to ActiveLock, ConcurrentLockSet and
LockSet, and see if the changes there have something to do with any
change of behaviour..

> Do we need
> InterruptException on synchronized (slaveRecoveryMonitor) in
> LogToFile.recover(...)? 

I don't think I changed that part of the code. I see that an interrupt
is just ignored there, so I think we can safely add a call to
"InterruptStatus.setInterrupted" there as well, if that's what you
mean. 

Generally I have just been concentrating on "normal operation" yet, so
far I haven't yet looked into things like replication, backup,
export/import, or even LOB/CLOB streams yet. I suspect there may be
issues with interrupts happening during I/O in those areas as well.

> Will change interrupt exception to statement
> level rather than session level require more code changes? Such as
> code in impl/store/raw/xact/* 

I don't know that for sure, but I suspected it might, the cleanup on
session termination just seemed safer and in line with what we already did
for interrupt exceptions. More investigation needed.

> I was just thinking statement level is more user friendly to
> application users.

Yes, I see that point. If we decide that's the way we would ultimately
like to go, I think I will still defer that to a next increment (maybe
a new JIRA issue?) of this work just to keep things simpler for now.


> 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-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, 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.