db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Date Tue, 09 May 2006 20:05:07 GMT
    [ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12378722 ] 

Kathey Marsden commented on DERBY-151:

I was wondering if anyone  could provide some expanded information on this issue. I am really
not all that familiar with running Derby in eclipse and have 
some probably very basic questions which are:

1)  I was wondering if  anyone  had some information on accessing Derby 
from within eclipse and avoiding ClosedByInterruptException  as 
described in  DERBY-151.  Do you always need to launch a separate thread for any Derby access
when running in eclipse?

2)  If the answer to #1 is "Yes",  is there a Derby solution to this problem that is possible
or is it strictly a user issue, for example, if the retry was implemented would that eliminate
the requirement to access Derby in a separate thread?

3) Are there any similar issues with  interuption when accessing with the client driver?

4) Is using embedded server ok with eclipse?  The plugins doc seems to 
imply that you should always use network server and access with Derby 


> Thread termination -> XSDG after operation is 'complete'
> --------------------------------------------------------
>          Key: DERBY-151
>          URL: http://issues.apache.org/jira/browse/DERBY-151
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions:
>  Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0)
>     Reporter: Barnet Wagman
>  Attachments: 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.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message