Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Message-ID: <1271017430.1126722114699.JavaMail.jira@ajax.apache.org>
Date: Wed, 14 Sep 2005 20:21:54 +0200 (CEST)
From: =?UTF-8?Q?J=C3=B6rg_von_Frantzius_=28JIRA=29?= <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-151) Thread termination -> XSDG after
 operation is 'complete'
In-Reply-To: <214516593.1108969729195.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

     [ http://issues.apache.org/jira/browse/DERBY-151?page=3Dall ]

J=C3=B6rg von Frantzius updated DERBY-151:
-------------------------------------

    Attachment: derby.log

Sorry, that was the wrong log! Could someone please delete it? It seems I c=
an't.
Here's the correct one (derby.log)

> 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, 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 thro=
ws an XSDG.
> The bug is a bit difficult to isolate but it occurs consistently in the f=
ollowing situation (with a particular database and an operation of a partic=
ular size):
> Derby is running in embedded mode with autocommit on. =20
> The application performs an INPUT operation from a thread that is not the=
 main thread.  The INPUT is issued using a PreparedStatement.  The INPUT ad=
ds ~ 256 records of six fields each. (Note that INSERTs of this size seem t=
o work fine in other contexts.)
> =20
> The preparedStatement.executeUpdate() seems to excute successfully; at le=
ast it returns without throwing an exception.=20
> 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 dis=
k, 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 exit=
s, 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

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