On Mon, 7 Nov 2005, Greg Monroe wrote:
I was thinking that by using CLOB/BLOB "handles" rather than a
binary array, the "effeciency coding" is passed on to the JDBC
implimentor. If you've got a good JDBC implimentation, when you
use the BLOB/CLOB *Stream methods, it will probably handle
buffering the reads and writes to the DB for you rather than
caching it in memory.
FWIW, I get worried about caching pictures in memory since we
do "face book" pages that have pictures and names with a lot of
people. Often, the pictures are user uploaded and end up being
"photo-quality" (e.g. 500K+) in size. But this is all just
part of dealing with large memory hog coding, and you always
have to recognize when your dealing with this sort of situation
and try to do the right thing.
Maybe we can address this after 3.2 is released, perhaps by defining
new Torque data types raw_blob and raw_clob, or setting a flag in the
column definition.
However, thinking more about it, I do not reckon this is an easy task.
As far as I know, you need an open db connection to read / write blobs or
clobs. How do we assure that the db connection is not returned to the pool
and no commit/rollback is made ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
