Hello.

I am reviewing this patch.    I am sorry for the long delay after the holidays. 
 I should be able to post comments Monday.    I am still working to understand 
the changes.


Thank you for your reviewing.
I wait for you :)

1) Javadoc - I think it would be good to add more javadoc even with the 
briefest description of the method function and parameters.

2) Tests - You had asked at one point I think about a location for tests.  I 
think largedata/loblengthTests could be modified to use a stream and then the 
jvmflags line removed.

I see.
I will work for these too, in the patch after the comments from you.

3) Code Formatting  - There seem to be code indentation inconsistencies in 
DDMWriter.  Also I think it is good to indent the method bodies  in the new 
methods in ReEncodedInputStream.java. Things sort of run together.

Reading comments from others, I think a patch for code formatting should be submitted separately from, because modification of code formatting would make it much difficult to read the patch.

Then I will file code formatting as new issue next to DERBY-326 after committed it.


Best regards.


Kathey Marsden (JIRA) wrote:

[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12362679 ]
Kathey Marsden commented on DERBY-326:
--------------------------------------

I am reviewing this patch.    I am sorry for the long delay after the holidays. 
 I should be able to post comments Monday.    I am still working to understand 
the changes.

A few general items
1) Javadoc - I think it would be good to add more javadoc even with the 
briefest description of the method function and parameters.

2) Tests - You had asked at one point I think about a location for tests.  I 
think largedata/loblengthTests could be modified to use a stream and then the 
jvmflags line removed.

3) Code Formatting  - There seem to be code indentation inconsistencies in 
DDMWriter.  Also I think it is good to indent the method bodies  in the new 
methods in ReEncodedInputStream.java. Things sort of run together.


Thanks

Kathey


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: 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.


--
/*

       Tomohito Nakayama
       [EMAIL PROTECTED]
       [EMAIL PROTECTED]
       [EMAIL PROTECTED]

       Naka
       http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/

Reply via email to