Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <8812981.135471287022413250.JavaMail.jira@thor>
Date: Wed, 13 Oct 2010 22:13:33 -0400 (EDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (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:all-tabpanel ]

Dag H. Wanvik updated DERBY-4741:
---------------------------------

    Attachment: derby-4741-nio-container+log+waits+locks+throws.stat
                derby-4741-nio-container+log+waits+locks+throws.diff

Uploading another experimental patch, derby-4741-nio-container+log+waits+locks+throws.

The change now is 
- some further generalizing of recovery logic in RAFContainer4, the readPage logic was missing some stuff I had added for writePage
- introduced InterruptTest#throwIf, which is a helper method to check & reset the thread's interrupt status and throw an SQLException (08000 for now) if set.
- added throwIf next to Query timeout logic in BasicNoPutResultSetImpl#checkCancellationFlag
- added throwIf before all returns in impl/jdbc/*.java in methods which call (directly or indirectly) handleException(t), typically this pattern:
       :
       InterruptTest#throwIf()
       return;
} catch (Throwable t) {
      throw handleException(t);
  
This will make sure Derby throws if it ever did see an interrupt during operation, which was intercepted for safety and postponed till a "safe place". This is a "catch-all", though, and I'll look for other  places closer to the
originating sites (container I/O, log I/O) so Derby could throw earlier. 

For example, commit can now throw if we see an interrupt during writing to log, cf. call to throwIf in EmbedConnection#commit.

Currently all interrupts throw 08000 which is session level, and none yet set the thread's intr flag. I will go over all usages of 08000 and set the flag next if we agree that's the right thing to do. Note that Derby151Test fails now, but InterruptTest should work and report all interrupts Derby see (some interrupts happen while the test is in application code; this is called out in the test's results). Btw, InterruptTest is not yet a JUnit test..

The patch is getting a bit large and unwieldy now, but not to worry, the patch is just a proof of concept, I'll break it down into smaller pieces before any proposed commit. Rerunning regressions.

I see Lily would prefer statement level error, rather than session level. I am sticking to session level for now since that's what the exisiting 08000 currently is. I'll go over the remaining *existing* usages of 08000 which I didn't already replace with "InterruptStatus.setInterrupted" + retry logic. If all are ok to replace, we could probably choose to change the exception to statement level rather than session level. If not, it might be confusing to have two kinds of SQLExceptions for interrupts, with different severity...


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