Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <30843272.27541286471131928.JavaMail.jira@thor>
Date: Thu, 7 Oct 2010 13:05:31 -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.stat
                derby-4741-nio-container+log.diff

Uploading derby-4741-nio-container+log, which builds on the previous
experimental patch in the following ways:

- Adds logic to recover when switching the log file gets interrupted
  (seen on Windows using Derby151Test). The retry had to precolate up
  from the NIO code, so I use an internal exception (temporarily
  borrow an exisiting one; should make a new one later)

- Makes RAFContainer4#getEmbryonicPage use a minion of readPage, so
  getEmbryonicPage can take advantage of the recovery machinery as
  well (it previously did a direct call to readFull, which made it
  vulnerable to being interrupted; this was also seen on Windows.

  Unfortunately, the latter could lead to deadlocks, because when
  getEmbryonicPage is called from writeRAFHeader, the thread has a
  lock on "this".  If another thread is has been interrupted and is
  about to do recovery, it would get stuck on waiting for the monitor
  on "this", while the getEmbryonicPage reader would get stuck on
  waiting on recovery to finish. To solve this, I had to let reads
  from getEmbryonicPage throw an internal exception so it can back out
  and release the monitor on "this" (in RAFContainer#clean), and do a
  retry from that level.

The patch is just a snapshot of my experiments, only intended so
people could comment on the approach. 


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