Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1778991151.1138107432984.JavaMail.jira@ajax.apache.org>
Date: Tue, 24 Jan 2006 13:57:12 +0100 (CET)
From: "Tomohito Nakayama (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-326) Improve streaming of large objects for
 network server and client
In-Reply-To: <651700908.1117536413494.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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

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

    Attachment: ReEncodedInputStream.java.modifiedForLongRun

This is a result of long run with modification of ReEncodedInputStream.java not to create buffer for each time.
Attached ReEncodedInputStream.java.modifiedForLongRun is ReEncodedInputStream after the modification.

=====================================================
TestRun =1
 Data from file to insert into Clob. =  file_500k.txt
 buffer (k) =1
 read blocks of data =false
 rows in table =100
Populating data
Data length inserted into clob = 537638
Avg time for test[1 ]=20661.984ms
=====================================================
=====================================================
TestRun =2
 Data from file to insert into Clob. =  file_500k.txt
 buffer (k) =1
 read blocks of data =false
 rows in table =100
Avg time for test[2 ]=20764.193ms
=====================================================
=====================================================
TestRun =3
 Data from file to insert into Clob. =  file_500k.txt
 buffer (k) =1
 read blocks of data =false
 rows in table =100
Avg time for test[3 ]=20772.66ms
=====================================================
=====================================================
TestRun =4
 Data from file to insert into Clob. =  file_500k.txt
 buffer (k) =1
 read blocks of data =false
 rows in table =100
Avg time for test[4 ]=20760.312ms
=====================================================
Throw away the result of the first run 
================OUTPUT=============================
Avg time taken to read 100rows+ (ignore first run )=20765ms

I found that it is a little faster than before patch.
However not so much ...


> 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, ReEncodedInputStream.java.modifiedForLongRun
>
> 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