db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TomohitoNakayama <tomon...@basil.ocn.ne.jp>
Subject Re: Where does the Client Driver expand object into memory before sending it ? (Re: [jira] Commented: (DERBY-1471) Implement layer B streaming for new methods defined in JDBC4.0)
Date Wed, 05 Jul 2006 14:32:14 GMT
Hello.

I think this should be told in DERBY-1472 more than DERBY-1471 ..

Best regards.

TomohitoNakayama wrote:

> Hello.
>
> Concerning about use of memory at driver,
> I briefly surveyed client driver program to find where *whole of* 
> object was expanded into memory before sending it,
> from code searched with keyword "writeScalarStream" as starting point 
> of survey.
>
> The result was as next.
>
> When org.apache.derby.client.am.Blob object was constructed with 
> parameter named binaryString typed as byte[],
> whole of object is expanded into memory before the call of constructor.
> But this seems not to be the scenario when InputStream was passed to 
> driver,
> reading around setBinaryStreamX method in the 
> org.apache.derby.client.am.PreparedStatement class.
>
> When org.apache.derby.client.am.Blob object was constructed with 
> parameter named binaryStream typed as InputStream,
> it seems that whole of object was *not* expanded into continuous memory.
> //Here, "continuous" means that it is true that the object is expanded 
> into *upper limited* memory array
> //segmentedly at writeScalarStream method in 
> org.apache.derby.client.net.Request.
>
> I'm not sure .....
>
> My question is what was the stackTrace found in DERBY-550 ...
> Does anyone have any information ?
> I searched received mails in my mailbox , but could not found the 
> information of stackTrace ....
>
> Now I found it not clear that the driver is writting all the file into 
> memory (RAM) before sending ...
>
> Deeper survey may be needed yet ...
>
> Best regards.
>
>
> Bryan Pendleton wrote:
>
>> > Kristian Waagan commented on DERBY-1471:
>> > ----------------------------------------
>> >
>> > The approach is to exhaust the application stream and copy it into
>> > memory to determine the length. If the data is too big to fit in 
>> memory,
>> > the client will fail with an out-of-memory exception.
>>
>> That seems fine to me. This is already the case with the current
>> API and implementation, I believe, so we aren't making anything worse.
>>
>> In practice, do application programs end up having *two* copies of the
>> BLOB/CLOB in client-side memory at the same time, one copy inside the 
>> Derby
>> code and one copy in the application code? Or is there actually only a
>> single copy of the BLOB/CLOB in memory? I'm asking only because it seems
>> like we might want to be clear about this in our documentation.
>>
>> thanks,
>>
>> bryan
>>
>>
>>
>

-- 
/*

        Tomohito Nakayama
        tomonaka@basil.ocn.ne.jp
        tomohito@rose.zero.ad.jp
        tmnk@apache.org

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

*/ 


Mime
View raw message