db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Date Wed, 06 Feb 2008 20:25:08 GMT

     [ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-151:
-------------------------------------

    Attachment: d151.java

Attached is a repro.

The good news is that from 10.3 the java.nio.channels.ClosedByInterruptException is linked
to the SQLException, so printStackTrace() will show that it's the underlying cause. But the
SQLException still says "please check if disk is full".

Another piece of good news: In an earlier comment, Suresh suggested that we could catch ClosedByInterruptException
and use that to reissue the sync() and/or give a better error message. The suggestion was
rejected because it would introduce a dependency on Java 1.4 in RAFContainer. From 10.3 we
have RAFContainer4 which *is* depending on Java 1.4, so that shouldn't stop us anymore.

> Thread termination -> XSDG after operation is 'complete'
> --------------------------------------------------------
>
>                 Key: DERBY-151
>                 URL: https://issues.apache.org/jira/browse/DERBY-151
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.0.2.1
>         Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0)
>            Reporter: Barnet Wagman
>         Attachments: d151.java, derby.log
>
>
> I've encountered what appears to be a bug related to threading. After an INSERT operation,
if the invoking thread terminates too quickly, Derby throws an XSDG.
> The bug is a bit difficult to isolate but it occurs consistently in the following situation
(with a particular database and an operation of a particular size):
> Derby is running in embedded mode with autocommit on.  
> The application performs an INPUT operation from a thread that is not the main thread.
 The INPUT is issued using a PreparedStatement.  The INPUT adds ~ 256 records of six fields
each. (Note that INSERTs of this size seem to work fine in other contexts.)
>  
> The preparedStatement.executeUpdate() seems to excute successfully; at least it returns
without throwing an exception. 
> The thread that invoked the INPUT operation then terminates (but NOT the application).
 The next INPUT operation then results in an
> "ERROR XSDG1: Page Page(7,Container(0, 1344)) could not be written to disk, please check
if disk is full."
> The disk is definitely not full.
> HOWEVER, if I put the calling thread to sleep for a second before it exits, the problem
does not occur.
> I'm not quite sure what to make of this.  I was under the impression that most of Derby's
activity occurs in the application's threads.  Could Derby be creating a child thread from
in the application thread, which dies when the parent thread terminates?
> Thanks

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