[
http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12363279 ]
Kathey Marsden commented on DERBY-326:
--------------------------------------
Great news about the performance indications.
Looking again at the patch, I have some error handling concerns. I wonder if
we can write negative tests for some of these negative cases.
- EXTDTAInputStream
openInputStreamLazily catches SQLExceptions/IOExceptions and throws an
IllegalStateException: I think this will mean that if there is an SQLException
on blob.getBinaryStream or clob.getCharacterStream. we may either terminate
the connection or hang.
-Several places SQLExceptions without SQLState. e.g
....
}catch (IOException e) {
throw new SQLException (e.getMessage())
}
Some other network server code imports org.apache.derby.impl.jdbc.Util; and
uses throw throw Util.javaException(e); which provide an SQLState.
- On the formatting the new patch actually removes indentation for statements
within method/constructor bodies in DDMWriter, so I would prefer the old one.
To indent, In my IDE (Eclipse) I check the box Indent "Statements within
method/constructor body". We have no code formatting guidelines even for new
code. I will remove any objection on this count.
> Improve streaming of large objects for network server and client
> ----------------------------------------------------------------
>
> Key: DERBY-326
> URL: http://issues.apache.org/jira/browse/DERBY-326
> Project: Derby
> Type: Improvement
> Components: Network Server, Network Client, Performance
> Reporter: Kathey Marsden
> Assignee: Tomohito Nakayama
> Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch,
> DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch,
> DERBY-326_5_indented.patch
>
> Currently the stream writing methods in network server and client require a
> length parameter. This means that we have to get the length of the stream
> before sending it. For example in network server in EXTDTAInputStream we have
> to use getString and getbytes() instead of getCharacterStream and
> getBinaryStream so that we can get the length.
> SQLAM Level 7 provides for the enhanced LOB processing to allow streaming
> without indicating the length, so, the writeScalarStream methods in
> network server DDMWriter.java and network client Request.java can be changed
> to not require a length.
> Code inspection of these methods seems to indicate that while the length is
> never written it is used heavily in generating the DSS. One strange thing is
> that it appears on error, the stream is padded out to full length with zeros,
> but an actual exception is never sent. Basically I think perhaps these
> methods need to be rewritten from scratch based on the spec requirements for
> lobs.
> After the writeScalarStream methods have been changed, then EXTDAInputStream
> can be changed to properly stream LOBS. See TODO tags in this file for more
> info. I am guessing similar optimizations available in the client as well,
> but am not sure where that code is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
