Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27109636.147731294184448759.JavaMail.jira@thor>
Date: Tue, 4 Jan 2011 18:40:48 -0500 (EST)
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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-4741?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1297=
7533#action_12977533 ]=20

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

Thanks for your thoughts on this, Knut.

Here is another issue: The NIO Channel#force call is used to implement sync=
 when we flush the Derby log, cf. this call:=20

LogToFile#flush -> LogAccessFile#syncLogAccessFile -> StorageRandomAccessFi=
le#sync -> getChannel().force(false)

The "false" here allows the skipping of flushing metadata, which makes this=
 faster (at least on Solaris) than the non-NIO
implementation of StorageRandomAccessFile#sync, which uses getFD().sync().

Unfortunately, an interrupt will make the getChannel().force call throw Clo=
sedChannelException, and I can't see an easy way
to recover from this, except assuming the log is corrupt and shutting down =
the database instance, so we can recover on reboot.

If we switch back to using "getFD().sync()", we would lose the performance =
optimization, but be resilient to interrupts.

So, unless somebody can see a way to finesse this problem, should be offer =
a knob to allow a user to trade this performance optimization for interrupt=
 resilience?

Aside: we also use StorageRandomAccessFile#sync in many other places, but i=
n those situations I find I am able to recover by closing the RAF, reopenin=
g and writing over again, since the data to be written is known, e.g. in Lo=
gToFile#initLogFile.=20

> 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, d=
erby-4741-a-02-api-interruptstatus.stat, derby-4741-a-03-api-interruptstatu=
s.diff, derby-4741-a-03-api-interruptstatus.stat, derby-4741-a-04-api-inter=
ruptstatus.diff, derby-4741-a-04-api-interruptstatus.stat, derby-4741-all+l=
enient+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-4=
741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff, derb=
y-4741-c-01-nio.stat, derby-4741-kristians-01.diff, derby-4741-nio-containe=
r+log+waits+locks+throws.diff, derby-4741-nio-container+log+waits+locks+thr=
ows.stat, derby-4741-nio-container+log+waits+locks-2.diff, derby-4741-nio-c=
ontainer+log+waits+locks-2.stat, derby-4741-nio-container+log+waits+locks.d=
iff, derby-4741-nio-container+log+waits+locks.stat, derby-4741-nio-containe=
r+log+waits.diff, derby-4741-nio-container+log+waits.stat, derby-4741-nio-c=
ontainer+log.diff, derby-4741-nio-container+log.stat, derby-4741-nio-contai=
ner-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 NI=
O classes java.nio.clannel.* for file io.
> If thread is interrupted while executing blocking IO operations in NIO, t=
he ClosedByInterruptException will get thrown. Unfortunately, Derby isn't c=
urrent 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 app=
lications can no longer access the database without a shutdown and reboot i=
ncluding a recovery.
> It would be nice if Derby could somehow detect and finish IO operations u=
nderway when thread interrupts happen before passing the exception on to th=
e application. Derby embedded is sometimes embedded in applications that us=
e Thread.interrupt to stop threads.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.