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: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
|