Kristian Waagan 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> 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 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.
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.
"The org.apache.derby.jdbc.EmbeddedDriver doesn't have this problem."
copied and pasted this from http://issues.apache.org/jira/browse/DERBY-550
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?
Yes. The locator based implementation will fix this issue.
"The network client will request LOB columns to be sent as LOB Locators
instead of data value bytes. Since the client no longer has a copy of
the LOB data value bytes, operations on the LOB data will be performed
on the server side, and the results of these operations will be sent to
the client."
More information can be found here
https://issues.apache.org/jira/browse/DERBY-208
regards,
