db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Network Client/Server BLOB
Date Wed, 28 Mar 2007 07:27:49 GMT
Raymond Kroeker wrote:
> Hello Kristian,
> 
>   Thank you for your reply.  In client/server mode the derby server 
> currently uses no jvm memory settings, however the derby client 
> application uses -Xms512m -Xmx1024m.

Okay. This is to be expected, as LOBs are currently materialized in the 
client when they are retrieved (and in some cases when they are sent to 
the server).
The LOCATOR-work will improve the clients ability to handle large LOBs 
on the server.

> 
>   The same blob is being written to and retreived from the database in 
> both the client and server software.  I have had successfull attempts at 
> storing 5 x 100MB blobs then had an out of memory error within the derby 
> network server when retreiving a 12MB blob.
> 
>   1.  My blobs vary in size.  Up to 100MB has worked, 12MB had a failure 
> in the network server.
>   2.  I insert them using  ps.setBinaryStream(1, stream, length); and 
> retreive them using rs.getBlob("CONTENT").getBinaryStream().  Both 
> workflows are issued from the database client.

Using the setBinaryStream with a length argument is good, and should 
allow you to stream any Blob to the server.

>   3.  The heap size for the derby server is default, the heap size of 
> the derb client is -Xms512m -Xmx1024m.
> 
>   I too have had no issue with respect to the embedded client, and my 
> out of memory error occured within the network server so I am confused a 
> little.

Did you run with Java SE 6 and get a stack trace when the OOME happened? 
If so, I'm sure it would be interesting to see where it happened for the 
people working on these issues. If you want stack traces with line 
numbers in them, you must download the debug-distribution (from the 
db.apache.org/derby site).

The Derby network server is a component/layer on top of the embedded 
driver. It is possible that even though the embedded driver is capable 
of handling Blobs up to 2GB-1, the network server might not be.



thanks,
-- 
Kristian

> 
> Raymond
> 
> On 3/27/07, *Kristian Waagan* <Kristian.Waagan@sun.com 
> <mailto:Kristian.Waagan@sun.com>> wrote:
> 
>     Raymond Kroeker wrote:
>      > I have encountered some entries in the mailing list suggesting that
>      > large BLOB content is not supported when using the
>      > network client/server.  By not supported I mean either the client
>     or the
>      > server run out of memory when the content is
>      > sufficiently large.
>      >
>      > My own tests on version 10.2.2.0 <http://10.2.2.0>
>     <http://10.2.2.0> suggest that this is
>      > not the case; however I wanted to know if anyone can provide a
>      > confirmation one way or another of this.  Thanks.
> 
>     Hello Raymond,
> 
>      From your mail I understand that you are able to use sufficiently
>     large
>     BLOBs for you purpose with Derby 10.2.2.0 <http://10.2.2.0> in
>     client/server mode.
>     Would you mind telling us a little more about your use of Derby?
> 
>     Quite some work has been done to remove problems with LOB handling in
>     Derby, and more work is being done as we speek (implementing
>     LOCATOR-based handling of LOBs).
>     That said, I'm not sure we are exactly where we want to be in Derby
>     10.2.2.0 <http://10.2.2.0>.
> 
>     A few questions;
>        1) How big are your BLOBs?
>        2) Do you both insert and retrieve them from/on the client?
>        3) What are your JVM settings? (heap size)
> 
> 
>     As far as confirmation goes, I have tested embedded earlier with 2GB-1
>     LOBs without out-of-memory problems. I am under the impression that
>     stream data still has to be materialized on the client before it is sent
>     to the server.
>     Can anyone else confirm this?
>     Will the LOCATOR-work fix the issue?
> 
> 
> 
>     regards,
>     --
>     Kristian
> 
>      >
>      > --
>      > ---------------------------------------------------------
>      > Raymond Kroeker
> 
> 
> 
> 
> -- 
> ---------------------------------------------------------
> Raymond Kroeker


Mime
View raw message