[
https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746389#action_12746389
]
Dag H. Wanvik commented on DERBY-151:
-------------------------------------
Running Knut's repro with Java 1.5 or 1.5, I see this error:
Java exception: 'org/apache/derby/impl/sql/execute/NormalizeResultSet:
java.lang.NoClassDefFoundError'.
Exception in thread "main" java.sql.SQLException: No current connection.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:158)
at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.java:262)
at
org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(EmbedConnection.java:2179)
at
org.apache.derby.impl.jdbc.EmbedConnection.createStatement(EmbedConnection.java:1334)
at
org.apache.derby.impl.jdbc.EmbedConnection.createStatement(EmbedConnection.java:1291)
at d151.main(d151.java:18)
which seems to be our old friend; the classloader being sensitive to the
interrupted flag in the thread. With 1.6
I see the disk is full message, though.
> 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, Derby151Test.java
>
>
> 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.
