db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Mon, 18 Oct 2010 15:07:22 GMT

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

Dag H. Wanvik edited comment on DERBY-4741 at 10/18/10 11:06 AM:
-----------------------------------------------------------------

Thanks for doing more measurements, Knut! It seems that even in the best case, the movePostion
operation is negatively impacted with 1-2% due to the ThreadLocal access, which is not desirable.

Knut mentioned that ContextService is already based on a ThreadLocal. I checked around a bit
and found that we might be able to get rid of the InterruptStatus thread local check in the
API methods in this way:

If we were able to retrieve the lcc at the point where we detect the interrupts and save this
fact in the lcc at that time, the cost of accessing a ThreadLocal variable would not be incurred
unless AN INTERRUPT ACTUALLY HAPPENED.

In the API methods, lcc is already available, and checking a boolean flag in the lcc instead
of calling InterruptStatus#throwIf (which accesses a thread local) would be much cheaper.
 I see we already sometimes do dig out the lcc in store level code, e.g. in store.access.DiskHashtable,
in this way:

    LanguageConnectionContext lcc   = (LanguageConnectionContext)
            ContextService.getContextOrNull(      // this call accesses a ThreadLocal
                LanguageConnectionContext.CONTEXT_ID);

I'll look into this approach a bit.


      was (Author: dagw):
    Thanks for doing more measurements, Knut! It seems that even in the best case, the movePostion
operation is negatively impacted with 1-2% due to the ThreadLocal access, which is not desirable.

Knut mentioned that ContextService is already based on a ThreadLocal. I checked around a bit
and found that we might be able to get rid of the InterruptStatus thread local check in the
API methods in this way:

If we were able to retrieve the lcc at the point where we detect the interrupts and save this
fact in the lcc at that time, the cost of accessing a ThreadLocal variable would not be incurred
unless AN INTERRUPT ACTUALLY HAPPENED.

In the API methods, lcc is already available, and checking a boolean flag in lthe cc instead
of calling InterruptStatus#throwIf (which accesses a thread local) would be much cheaper.
 I see we already sometimes do dig out the lcc in store level code, e.g. in store.access.DiskHashtable,
in this way:

    LanguageConnectionContext lcc   = (LanguageConnectionContext)
            ContextService.getContextOrNull(      // this call accesses a ThreadLocal
                LanguageConnectionContext.CONTEXT_ID);

I'll look into this approach a bit.

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


Mime
View raw message