db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6228) DisconnectException when executing an SELECT [LOB column] ORDER BY [...] statement with TYPE_SCROLL_[IN]SENSITIVE and CONCUR_UPDATABLE
Date Sat, 19 Oct 2013 19:01:42 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799979#comment-13799979
] 

Dyre Tjeldvoll commented on DERBY-6228:
---------------------------------------

I have verified that the exception comes from the client not being able to parse the {{SQLCARD}}
added to the reply as a result of the downgrade warning. Adding code to parse the warning
removes the crash, but you cannot see the warning since the warning gets cleared later, which
is probably another bug.

If you change c to {{VARCHAR(32)}} it does not fail. Which is reasonable, since this downgrade
*is* tested in {{SURTest.testDowngradeToScrollReadOnly()}}, but I'm guessing not with a LOB.
The interesting thing here is that the warning is *only* produced when *creating* a {{ResultSet}},
so we would expect to see this warning on the previous line where the {{ResultSet}} object
is actually created. And sure enough, if you modify the repro so that it prints warnings before
calling {{next()}}, you'll see the downgrade-warning. I'm guessing that {{getRowCount()}}
creates a temporary {{ResultSet}} with the same attributes as the one just created so that
it too gets the downgrade warning, but this warning is added to the {{next()}}-reply, which
is not set up to handle it.

> DisconnectException when executing an SELECT [LOB column] ORDER BY [...] statement with
TYPE_SCROLL_[IN]SENSITIVE and CONCUR_UPDATABLE
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6228
>                 URL: https://issues.apache.org/jira/browse/DERBY-6228
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.8.3.0, 10.10.1.1
>            Reporter: Lukas Eder
>              Labels: derby_triage10_11
>         Attachments: Derby6228.java
>
>
> Here's a minimal program to reproduce the issue:
>         Connection c = DriverManager.getConnection(
>             "jdbc:derby://localhost:1527/test;create=true", "TEST", "TEST");
>         Statement s = c.createStatement();
>         s.executeUpdate(
>             "CREATE TABLE t(" +
>                 "id INT NOT NULL, " +
>                 "c CLOB" +
>             ")");
>         s.executeUpdate("INSERT INTO t VALUES (1, null)");
>         s.executeUpdate("INSERT INTO t VALUES (2, null)");
>         PreparedStatement stmt = c.prepareStatement(
>             "SELECT * FROM t ORDER BY id",
>             ResultSet.TYPE_SCROLL_INSENSITIVE,
>             ResultSet.CONCUR_UPDATABLE);
>         ResultSet rs = stmt.executeQuery();
>         rs.next();
> The above leads to this exception:
> java.sql.SQLNonTransientConnectionException: Netzwerkprotokollausnahme: DSS-Länge ist
beim Beenden des Parsing-Vorgangs der ID-Kette größer als 0. Die Verbindung wurde beendet.
> 	at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.ResultSet.next(Unknown Source)
> 	at org.jooq.test._.testcases.KeepResultSetTests.testKeepRSWithUpdateOnChangeLazy(KeepResultSetTests.java:330)
> 	at org.jooq.test.jOOQAbstractTest.testKeepRSWithUpdateOnChangeLazy(jOOQAbstractTest.java:2240)
>         ...
> Caused by: org.apache.derby.client.am.DisconnectException: Netzwerkprotokollausnahme:
DSS-Länge ist beim Beenden des Parsing-Vorgangs der ID-Kette größer als 0. Die Verbindung
wurde beendet.
> 	at org.apache.derby.client.net.Reply.endOfSameIdChainData(Unknown Source)
> 	at org.apache.derby.client.net.NetResultSetReply.readPositioningFetch(Unknown Source)
> 	at org.apache.derby.client.net.ResultSetReply.readPositioningFetch(Unknown Source)
> 	at org.apache.derby.client.net.NetResultSet.readPositioningFetch_(Unknown Source)
> 	at org.apache.derby.client.am.ResultSet.getRowCount(Unknown Source)
> 	at org.apache.derby.client.am.ResultSet.resultSetContainsNoRows(Unknown Source)
> 	at org.apache.derby.client.am.ResultSet.getNextRowset(Unknown Source)
> 	at org.apache.derby.client.am.ResultSet.nextX(Unknown Source)
> 	... 30 more
> To reproduce the above, all of the following things seem relevant:
> 1. There is at least one BLOB or CLOB column being selected
> 2. An ORDER BY clause is added
> 3. ResultSet.TYPE_SCROLL_SENSITIVE or ResultSet.TYPE_SCROLL_INSENSITIVE is set
> 4. ResultSet.CONCUR_UPDATABLE is set



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message