You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Jörg von Frantzius (JIRA)" <de...@db.apache.org> on 2005/09/14 20:19:55 UTC
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
[ http://issues.apache.org/jira/browse/DERBY-151?page=all ]
Jörg von Frantzius updated DERBY-151:
-------------------------------------
Attachment: .log
Alright, I didn't think of that! Here's the log (I think the last shutdown can be ignored).
> 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: 10.0.2.1
> Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0)
> Reporter: Barnet Wagman
> Attachments: .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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira