You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/08/02 17:32:49 UTC

Using StorageFactory to create temporary files

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

Re: Using StorageFactory to create temporary files

Posted by Anurag Shekhar <An...@Sun.COM>.
Mike Matrigali wrote:
>
>
> Anurag shekhar wrote:
>> 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.
> will this code ever be used on the client side of a network 
> client/server configuration?
>
No its part Blob/Clob classes on EmbeddedDriver.
anurag

Re: Using StorageFactory to create temporary files

Posted by Mike Matrigali <mi...@sbcglobal.net>.

Anurag shekhar wrote:
> 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.
will this code ever be used on the client side of a network 
client/server configuration?


Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Anurag Shekhar <An...@Sun.COM>.
derby-1341 is only for Embedded Driver.
anurag
Mike Matrigali wrote:
>
>
> Suresh Thalamati wrote:
>> Anurag shekhar wrote:
>>
>>> I need to grant derby.jar read,write,delete access on tmp directory 
>>> (issue derby-1341).
>>> I tried adding
>>>  permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read, 
>>> write, delete";
>>>
> ...
>>
>> Any reason why these temp files can not be created under database 
>> temp directory  (derby.storage.tempDirectory)( may be in a seperate 
>> directory under that). This might save users from adding permission 
>> to yet another location seperately.
>>
>> Thanks
>> -suresht
> As I understand this, this usage is for client side action so should 
> not assume anything about the server storage space.  In network 
> client/server configuration it is likely the database does not even 
> exist on the machine where the client resides.
>


Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Mike Matrigali <mi...@sbcglobal.net>.

Suresh Thalamati wrote:
> Anurag shekhar wrote:
> 
>> I need to grant derby.jar read,write,delete access on tmp directory 
>> (issue derby-1341).
>> I tried adding
>>  permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read, 
>> write, delete";
>>
...
> 
> Any reason why these temp files can not be created under database temp 
> directory  (derby.storage.tempDirectory)( may be in a seperate directory 
> under that). This might save users from adding permission to yet another 
> location seperately.
> 
> Thanks
> -suresht
As I understand this, this usage is for client side action so should not 
assume anything about the server storage space.  In network 
client/server configuration it is likely the database does not even 
exist on the machine where the client resides.


Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Suresh Thalamati <su...@gmail.com>.
Mike Matrigali wrote:
> 
> 
> Anurag Shekhar wrote:
> 
>> I can use database tmp file system. I can get the tmp directory name 
>> from StorageFactory. Or is there some better way of getting this 
>> directory ?
>> anurag
> 
> 
> I don't think you should be using the database tmp file system for
> client code.  You at least must code for when database file system
> is not on the current machine for the client/server configuration.  So
> might as well make it consistent for all client code.
> 
> 

I agree if it is client specific case, database tmp file directory
should not be used.

sorry,  I have not got around reading this thread completely before
posting my questions.

In case of an embedded encrypted database, is it ok for the jdbc layer 
to create temp files that are not encrypted ?


Thanks
-suresh



Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Mike Matrigali <mi...@sbcglobal.net>.

Anurag Shekhar wrote:
> I can use database tmp file system. I can get the tmp directory name 
> from StorageFactory. Or is there some better way of getting this 
> directory ?
> anurag

I don't think you should be using the database tmp file system for
client code.  You at least must code for when database file system
is not on the current machine for the client/server configuration.  So
might as well make it consistent for all client code.


Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Anurag Shekhar <An...@Sun.COM>.
I can use database tmp file system. I can get the tmp directory name 
from StorageFactory. Or is there some better way of getting this directory ?
anurag
Suresh Thalamati wrote:
> Anurag shekhar wrote:
>> I need to grant derby.jar read,write,delete access on tmp directory 
>> (issue derby-1341).
>> I tried adding
>>  permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read, 
>> write, delete";
>>
>> in this section
>> grant codeBase "${derbyTesting.codejar}derby.jar"
>>
>> I continue to get security exception while creating a temporary file. 
>> But when I add same permission to all (grant {}) it works fine.
>> What am i doing wrong here ?
>> thanks
>> anurag
>>
>> Daniel John Debrunner wrote:
>>
>>> Anurag Shekhar wrote:
>>>
>>>
>>>  
>>>
>>>> Yes java.io.File.createTempFile() will work. But is it ok to grant 
>>>> file
>>>> i/o access to a jdbc driver class ?
>>>>     
>>>
>>>
>>> Permissions afre granted to derby.jar, not individual classes.
>>>
>>> Dan.
>>>
>>>
>>>
>>>   
>>
>>
>>
>
> Any reason why these temp files can not be created under database temp 
> directory  (derby.storage.tempDirectory)( may be in a seperate 
> directory under that). This might save users from adding permission to 
> yet another location seperately.
>
> Thanks
> -suresht
>
>


Re: adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Suresh Thalamati <su...@gmail.com>.
Anurag shekhar wrote:
> I need to grant derby.jar read,write,delete access on tmp directory 
> (issue derby-1341).
> I tried adding
>  permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read, 
> write, delete";
> 
> in this section
> grant codeBase "${derbyTesting.codejar}derby.jar"
> 
> I continue to get security exception while creating a temporary file. 
> But when I add same permission to all (grant {}) it works fine.
> What am i doing wrong here ?
> thanks
> anurag
> 
> Daniel John Debrunner wrote:
> 
>> Anurag Shekhar wrote:
>>
>>
>>  
>>
>>> Yes java.io.File.createTempFile() will work. But is it ok to grant file
>>> i/o access to a jdbc driver class ?
>>>     
>>
>>
>> Permissions afre granted to derby.jar, not individual classes.
>>
>> Dan.
>>
>>
>>
>>   
> 
> 
> 

Any reason why these temp files can not be created under database temp 
directory  (derby.storage.tempDirectory)( may be in a seperate 
directory under that). This might save users from adding permission to 
yet another location seperately.

Thanks
-suresht



adding permission to derby_tests.policy(was:Re: Using StorageFactory to create temporary files)

Posted by Anurag shekhar <An...@Sun.COM>.
I need to grant derby.jar read,write,delete access on tmp directory 
(issue derby-1341).
I tried adding
  permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read, 
write, delete";

in this section
grant codeBase "${derbyTesting.codejar}derby.jar"

I continue to get security exception while creating a temporary file. 
But when I add same permission to all (grant {}) it works fine.
What am i doing wrong here ?
thanks
anurag

Daniel John Debrunner wrote:
> Anurag Shekhar wrote:
>
>
>   
>> Yes java.io.File.createTempFile() will work. But is it ok to grant file
>> i/o access to a jdbc driver class ?
>>     
>
> Permissions afre granted to derby.jar, not individual classes.
>
> Dan.
>
>
>
>   


Re: Using StorageFactory to create temporary files

Posted by Daniel John Debrunner <dj...@apache.org>.
Anurag Shekhar wrote:


> Yes java.io.File.createTempFile() will work. But is it ok to grant file
> i/o access to a jdbc driver class ?

Permissions afre granted to derby.jar, not individual classes.

Dan.




Re: Using StorageFactory to create temporary files

Posted by Anurag Shekhar <An...@Sun.COM>.
Daniel John Debrunner wrote:
> Anurag shekhar wrote:
>   
>> 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.
>>     
>
> But there is no mechansim on the client to define one is running on "a
> special storage", are you going to define one?
>   
I am not using storage factory in client driver. I am using it in set 
methods of lob classes in EmbeddedDriver's Blob/Clob classes.
> In this case it seems using the simple java.io.File.createTempFile()
> will solve all of your issues. What benefit do you get from using
> StorageFactory and its *current* set of implementations?
>
>   
Yes java.io.File.createTempFile() will work. But is it ok to grant file 
i/o access to a jdbc driver class ?


thanks
anurag

Re: Using StorageFactory to create temporary files

Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:

> Anurag shekhar wrote:
> 
>>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.
> 
> 
> But there is no mechansim on the client to define one is running on "a
> special storage", are you going to define one?
> 
> In this case it seems using the simple java.io.File.createTempFile()
> will solve all of your issues. What benefit do you get from using
> StorageFactory and its *current* set of implementations?

I think this is also true for embedded, using the
java.io.File.createTempFile() is the cleanest solution.

The StorageFactory is there to allow the database store to handle
different file types (jar, classpath, java i/o) and there is a
demonstrated need for this. Thus the database store consistently uses
the StorageFactory interfaces to access files and directories.  The
database store also needs temporary files and it needs them to be
handled using the same api's as the perisisent files. Thus
StorageFactory has a getTempDir() method, it's purpose in life is to
bring temp files into the world of the database store, not a general
purpose mechanism.

Dan.




Re: Using StorageFactory to create temporary files

Posted by Daniel John Debrunner <dj...@apache.org>.
Anurag shekhar wrote:
> 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.

But there is no mechansim on the client to define one is running on "a
special storage", are you going to define one?

In this case it seems using the simple java.io.File.createTempFile()
will solve all of your issues. What benefit do you get from using
StorageFactory and its *current* set of implementations?

Dan.



Re: Using StorageFactory to create temporary files

Posted by Anurag shekhar <An...@Sun.COM>.
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
>>
>>
>


Re: Using StorageFactory to create temporary files

Posted by Mike Matrigali <mi...@sbcglobal.net>.
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
> 
>