Let me explain why I need a temporary file. I need a storage where
blob/clob can be stored before writing into the table. As the size of
lob can go upto 2gb its not possible to keep it in memory. I am using
the temporary file to keep the byte/string in case the the size grows
more than 4k.
So the temporary file will be created and accessed from the jdbc driver.
I decided to use StorageFactory because it already have the nessasary
permission for disk i/o. In case derby is running on a special storage,
the StorageFactory will be aware of it and will be able to create
temporary file for that device.
thanks
anurag
Mike Matrigali wrote:
This is an unexpected usage, this was never designed for that purpose.
It was originally designed as a module only to be used underneath the
store module. The purpose was to allow alternate implementations of
the underlying filesystem.
I wonder why straight java i/o stream interfaces were not used? Is
there anything being provided by the StorageFactory that a direct
use of java io does not easily provide?
I think it would be especially a bad idea to use the storage factory
on the client side of network server as it is going to draw in a lot
of other stuff not currently needed by the client jar.
Rick Hillegas wrote:
The patch attached to DERBY-1341 uses the StorageFactory to create a
temporary file on behalf of the embedded JDBC layer. Is this usage
OK? Does this violate some assumptions about what server layers are
allowed to use the StorageFactory?
Would appreciate guidance here. I am out of my depth.
Thanks,
-Rick
