--- In Firebird-Java@yahoogroups.com, Rick Fincher <rnf@...> wrote:

>
> Hi Phil,
>
> If you use a ResultSet with autocommit mode on, the entire thing gets
> returned at once uses all the memory available for Java that the JDBC
> driver is running in. Turn off autocommit and give it a try.
>
> Be aware, though, that you must have enough memory allocated to the JVM
> to read the largest graphic you will ever retrieve or you will get the
> OOM exception. You may not be able to guarantee this if your app gets
> deployed elsewhere.
>
> The size problem is probably a result of padding the buffers in the
> stream/blob reads. You can get around that by storing the image

size in

> a field of the record, then reading the size upon retrieval of the
> image, and only reading that number of bytes from the stream and

putting

> them in the image.
>
> It is also helpful to store info like mime-type, creation date,

original

> filename, etc. if you might ever need to access the image through a web
> app or store it back to disk as a file.
>
> Hope this helps,
>
> Rick

Hi Rick, thanks for your reply. Autocommit is not on... and I'm
embarassed to say I posted my problem a little early, after a couple
of days of frustration. It turns out the object size WAS correct and
consistent, and I'd made so many changes I'd lost track of the correct
objects. Sorry about that.
But your tips re. possible padding of the buffers is interesting -
I'll keep an eye on that, but as it happens it seems the bytes read is
correct. I also already store most of the parameters you suggest...

Despite all this, I still cannot read/write the large blobs (my
troublesome one is 9.5MB) without OOM exceptions, but I've come to the
conclusion that the large blobs that are giving me problems (they
aren't images) can be skipped from my process.... so for now I can
probably just avoid it, but it's a pretty crappy solution :(

Once again thanks for your comments and sorry for posting the wrong
message about the wrong blob size...

Thanks, Phil