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 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:24:23 GMT

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 

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

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



View raw message