[
https://issues.apache.org/jira/browse/DERBY-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dyre Tjeldvoll updated DERBY-6228:
----------------------------------
Attachment: derby-6228-a.diff
Uploading a patch which:
* Fixes the original crash by adding parsing of the {{SQLCARD}} containing the
downgrade warning.
* Makes the {{getWarnings()}} statement not auto-committable so that the
transaction is not committed when calling {{getWarnings()}}
* Saves the value of {{isValidCursorPosition_}} when calling
{{moveToInsertRow()}} so that that it can be restored to the correct value when
leaving the insert row. Previously {{isValidCursorPosition_}} was
unconditionally set to true when leaving the insert row, which resulted in an
attempt to release locators for a non-valid row, which failed.
* Adds an additional check to {{LOBStateTracker.checkCurrentRow()}} which
avoids trying to release locators if positioned on a deleted row. This is
necessary because {{isValidCursorPosition_==true}} for a deleted row.
(Immediately after calling {{deleteRow()}} the result set is not positioned on
any row, but it is still possible to navigate to the deleted row. And since
{{isValidCursorPosition_==true}} an attempt at releasing locators will be made
when leaving the deleted row, but this will fail since no locators were created
when navigating to the deleted row.
* Adds a {{CLOB}} column to the data model used by the SUR-tests to verify the
fix.
> 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: derby-6228-a.diff, 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)
