[ http://issues.apache.org/jira/browse/DERBY-326?page=all ]
Sunitha Kambhampati updated DERBY-326:
--------------------------------------
Attachment: ClobTest.zip
Thanks Tomohito for the patch. I wanted to try a simple clob test with reads
and see if there was any difference performance wise. But I could not apply the
latest patch cleanly maybe because some changes were submitted today. I have
attached a zip file with the test file and a script to run it. Currently the
test inserts clob of size ~500k and then does read of all the rows in the
table. It would be great if you could run it before and after your changes to
see the difference. Please feel free to make changes to the test or change
the parameters to the test. Thanks.
> 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 Client, Performance, Network Server
> 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
>
> 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
