[
https://issues.apache.org/jira/browse/DERBY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666688#comment-13666688
]
Mike Matrigali commented on DERBY-6214:
---------------------------------------
so comparing embedded to client/server is likely not very useful in the
setObject and setString case. In embedded we have the actual string so there
is no stream, so nothing to get closed after draining, so no problem. In
client/server we are going to send a stream over and we are not going to know
if it is small or big so we probably can't just create an object in memory to
"back" up the stream on the server side.
I might suggest looking at embedded in one of the setStream cases with a stream
larger than 32k, and see if it works for an update of more than one row. If it
does it might lead to existing mechanism to save off a stream so that it can be
reopened. I believe there are existing holder objects that will take a stream
and
buffer it to disk if need be so that you can read it again.
One thing I don't know is if it should be the job of server side client/server
code that you are looking at to do this, of if it should be the job of sql
execution engine
to recognize an input clob/blob/stream can't be read twice and it should do
this work in the case of an update that might require updating more than one
row.
I think we use to have generic embedded issues with blob/clob where it would
instantiate them into memory in cases like this. I thought those had been
resolved,
but maybe this is a case that slipped through. Should be clear if you follow
the code for an embedded update of clob where user provides 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_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
