Hello.

I follow myself about testing ...

Testing :
  * Executed derbyall and found no error.

I did *not* executed derbyall suite for removing format change in source code.

The derbyall suite was executed only in DERBY-326.patch.

Concerning DERBY-326_2.patch, it was confirmed that source code was compiled and that no error was found in result from execution of jdbcapi/Stream.java.


Best regards.



Tomohito Nakayama (JIRA) wrote:

    [ http://issues.apache.org/jira/browse/DERBY-326?page=all ]

Tomohito Nakayama updated DERBY-326:
------------------------------------

   Attachment: DERBY-326_2.patch

I re-upload DERBY-326_2.patch.
I created patch *after* applying patch created executing "svn diff --diff-cmd diff 
-x -uw".

Description of patch :
  * Remove processing to expand data from InputStream of blob/clob to memory 
before sending to client.
   * Implement layer B streaming at NetworkServer.
    * As written in this issue firstly, almost rewrite whole 
org.apache.derby.impl.drda.DDMWriter#writeScalarStream.
      Here , "almost" means that code was not wrote from scratch, but was wrote 
as reform.
      Remarkable point is as next :
      Original code was using variable "bytesToRead" to handle remaining amount 
of data sent and remaining roon in DSS segment .
      Now this variable "bytesToRead" was removed from.
      New code, instead, have variable "spareDssLength" to handle remaining 
room in DSS segment .
* Modify org.apache.derby.impl.drda.EXTDTAInputStream to stream InputStream retrieved from ResultSet directly.
    * The source stream is read twice, first for seeing whether source stream 
is/is not empty, second for streaming it.
    * To keep reference to valid stream, EXTDTAInputStream have reference to 
resultset and blob/clob also.
* Modify master file of result for blobclob4BLOB.
   * Now as same as result of embed driver, dead lock will be happen in 
clobTest92.
   * Different expected exception was happen in negative test in blobclob4BLOB.
Testing :
  * Executed derbyall and found no error.

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

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