[
https://issues.apache.org/jira/browse/DERBY-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538712
]
Kristian Waagan commented on DERBY-1599:
----------------------------------------
This looks like a programming error somewhere in the JDBC layer. A stream of an
unexpected type is seen in EmbedClob init, which indicates an odd path through
the system. My comments are regarding the embedded driver.
I think there are numerous scenarios to consider here. As far as I can tell,
the stream data will be materialized if you call for instance rs.getString().
Fair enough, if you ask for lots of data in memory, Derby just have to do as
told. However, the following scenario fails and looks very much like a bug:
a) Call rs.updateCharacterStream() with a stream.
b) Call rs.getCharacterStream() and drain the stream.
c) Call rs.updateRow().
Step c will fail (only excerpt below):
Caused by: java.io.EOFException: Stream has already been read and end-of-file
reached and cannot be re-used.
at
org.apache.derby.iapi.types.ReaderToUTF8Stream.read(ReaderToUTF8Stream.java:151)
at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:320)
at org.apache.derby.iapi.types.SQLChar.readExternal(SQLChar.java:649)
at org.apache.derby.iapi.types.SQLChar.getString(SQLChar.java:363)
at org.apache.derby.iapi.types.SQLChar.setFrom(SQLChar.java:1229)
at org.apache.derby.iapi.types.DataType.setValue(DataType.java:490)
at
org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3714)
The problem here seems to be that Derby just passes the source stream directly
out to the user.
If we want this scenario to work, we must somehow store the data temporarily.
Since we don't know the size, we must also be prepared to store it on disk. I
believe we already have a solution for this, where it is kept in memory until
it reaches a threshold and then it is written to disk. I have not checked if
the code can be used as-is, or if it must be customized.
The case with EmbedClob.init() is basically the same, but is has an assert that
triggers.
Has anyone consulted the JDBC spec on this issue?
What is the defined behavior, if any?
> Clob.getSubString() throws NullPointerException when created by updatable
> result set
> ------------------------------------------------------------------------------------
>
> Key: DERBY-1599
> URL: https://issues.apache.org/jira/browse/DERBY-1599
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Knut Anders Hatlen
> Priority: Minor
> Attachments: Repro.java
>
>
> If you create a clob value with one of the ResultSet.updateXXX methods that
> take a stream or a reader, and retrieve that value with ResultSet.getClob(),
> a NullPointerException will be thrown when getSubString() is called on the
> returned Clob object. This happens with the network client driver, and it has
> been observed on Derby 10.1.3.1 and trunk.
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.derby.client.am.Clob.getSubStringX(Clob.java:229)
> at org.apache.derby.client.am.Clob.getSubString(Clob.java:210)
> at Repro.main(Repro.java:24)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
