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] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Fri, 22 Oct 2010 18:26:05 GMT

     [ 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-a-01-api-interruptstatus.stat
                derby-4741-a-01-api-interruptstatus.diff

Uploading a first rev of a patch for part a): derby-4741-a-01-api-interruptstatus
Regressions ran ok modulo a hang in BootLockTest.

This patch contains the new helper class InterruptStatus and inserts calls to
restoreIntrFlagIfSeen in before API methods' return and in the exception handling (TransactionResourceImpl#handleException).

Execution of EmbedStatement#executeBatch check of interrupts and throws 08000 if seen between
each statement in the batch.

Note: Still, the machinery of InterruptStatus isn't used to save any interrupts, that follows
in a later patch, so this patch doesn't change behavior. The focus here is on the correct
placement of calls to
restoreIntrFlagIfSeen in the API.  Reviews appreciated!

------------------------ Patch details:

- iapi.util.InterruptStatus: new helper class for keeping track of detected and
  postponed interrupts

- LanguageConnectionContext
  GenericLanguageConnectionContext: 

  Methods to set/reset threads interrupt status flag to allow us to clear the thread's actual
flag temporarily, and to reset it when we return to the user application, possibly by throwing
an interrupted SQLException (SQL state 08000) if we cut something short. It also contains
methods to save and retrieve the stack frame at the point an interrupt was detected. This
is used when we throw the interrupt exception. See also its Javadoc.

- TransactionResourceImpl: resurrect the thread's interrupt status flag on SQL error (called
from handleException). Use lcc if available, else thread local variable.

- EmbedBlob, for methods that call handleException inside synchronized on connection: use
InterruptStatus.restoreIntrFlagIfSeen(lcc) before return

- EmbedResultSet: for methods that call handleException inside synchronized on connection:
use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return

- EmbedStatment: for methods that call handleException inside synchronized on connection:
use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return
 
  In executeBatch, use throwIf between each statement in the batch: if we saw an interrupt,
stop execution of batch. Note that if we do throw, restoreIntrFlagIfSeen will be called in
the finally block, but it is idempotent, so no harm is done. It is necessary in case we saw
an interrupt in the last statement of the batch.

- EmbedDatabaseMetaData: for methods that call handleException inside synchronized on connection:
use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return

- EmbedPreparedStatement: for methods that call handleException inside synchronized on connection:
use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return

- EmbedConnection.java: for methods that call handleException inside synchronized on connection:
use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return

  For createDatabase, use InterruptStatus.restoreIntrFlagIfSeen() which inspects the thread
local variable. This should catch I/O interrupts seen during the database creation phase.

  Special handling in #close to make sure we access lcc while it is still available.


> 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-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat, 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