Daniel John Debrunner wrote:
Oystein Grovlen - Sun Norway wrote:
Daniel John Debrunner (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465625
]
Daniel John Debrunner commented on DERBY-2247:
----------------------------------------------
Why use the system temp folder and not the database's? The
database's temp folder will be cleaned up on re-boot.
Could a existing store file be used so that encrpytion support
would already be there?
I was planning to use database tmp directory and one of the patch
in the parent issue uses database tmp directory and StoreFactory
but lattered in the disscussion it was concluded that the store api
and tmp file system are not supposed to be used for creating random
files which are not part of database.
I thought that discussion was about using store code in the network
client., whereas this is about using the code in embedded. With
embedded the code is there and will by definition already have the
correct security permissions set up.
The discussion on this can be found here:
http://www.nabble.com/Using-StorageFactory-to-create-temporary-files-tf2040526.html
I think Anurag's patch follows what was suggested in that discussion.
Some excerpts from that discussion:
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?
Daniel John Debrunner wrote:
> 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.
Doh, got me. :-) My only excuse is that when I wrote recommending
createTempFile() I hadn't thought about needing encryption which
Anurag pointed out along with his patch. Given that "new" requirement
I wonder if there is a way to use the existing code that handles disk
files.
Dan.
Using StoreFactory doesn't unnecessarily enables encryption. As far
as I know the encryption is implemented at a higher level from storage
layer. For temporary storage I will need a flat file hence need to use
StorageRandomAccessFile which doesn't have support for encryption. But I
still prefer if we can have these temporary file within database
temporary directory because
1. all the files related to one db is created in one location
2. cleanup at the time of startup
3. You can be sure that we have write access. If general tmp system is
used, we might get problems not discovered during boot. Right now derby
doesn't asks user to provide a writable temp directory unless its a
readonly database.
anurag
