[
https://issues.apache.org/jira/browse/DERBY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-6214:
-----------------------------------
Attachment: DERBY6214_patch3_stat.txt
DERBY6214_patch3_diff.txt
Since CrossConverters.setObject is heavily used by various
PreparedStatement.setXXX, ResultSet.getXXX, Resultset.updateXXX methods, the
only change I am proposing there is to check the length of the String object if
the type of the column is ClientTypes.CLOB and if yes, then return a String
object if the String is less than or equal to 10922 characters otherwise return
it as a CLOB object. The caller would use the returned object (String or CLOB)
other than the ResultSet.updateObject and ResultSet.updateString methods when
they are working with CLOB columns. These methods are coded to expect a CLOB
object from CrossConverters.setObject call, irrespective of the length of the
String. Because of this, these 3 methods will convert the returned String
object to CLOB so that the rest of the code does not break. The junit and
derbyall run fine with this patch. Please let me know if there is any feedback.
The ideal solution would be to not change the Client code at all and have the
engine deal with reading the stream more than once when UPDATE can update more
than one row and it is dealing with a stream.
> PreparedStatement.setObject(int, Object, Types.CLOB) fail with DerbyNet
> -----------------------------------------------------------------------
>
> Key: DERBY-6214
> URL: https://issues.apache.org/jira/browse/DERBY-6214
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.8.3.0, 10.9.1.0
> Reporter: Rong Qu
> Assignee: Mamta A. Satoor
> Attachments: Derby6214.java, DERBY6214_patch1_diff.txt,
> DERBY6214_patch1_stat.txt, DERBY6214_patch2_diff.txt,
> DERBY6214_patch3_diff.txt, DERBY6214_patch3_stat.txt, Derby6214_setup.sql,
> Derby6214_ver2.java, derby.log, DerbyNet_client_test.sql
>
>
> The issue is specific to the DerbyNet client driver, and doesn't seem to
> occur using embedded Derby.
> "PreparedStatement.setObject(int, Object, Types.CLOB)". It seems to be a
> problem updating a CLOB column with a parameterized value using the DerbyNet
> client driver, and if the update SQL ends up updating more than one row. I
> attached a simple test case that just uses JDBC to reproduce the error. The
> exception looks like this:
> org.apache.derby.client.am.BatchUpdateException: Non-atomic batch failure.
> The batch was submitted, but at least one exception occurred on an individual
> member of the batch. Use getNextException() to retrieve the exceptions for
> specific batched elements.
> at org.apache.derby.client.am.Agent.endBatchedReadChain(Unknown Source)
> at
> org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown
> Source)
> ...
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element
> #0: An unexpected exception was thrown
> at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
> at
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown
> Source)
> at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown
> Source)
> at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source)
> at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown
> Source)
> ... 4 more
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element
> #0: Java exception: 'Stream has already been read and end-of-file reached and
> cannot be re-used.: java.io.EOFException'.
> at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> ... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
