client/server: h2 temp files creation on client's execution direcotry fails

[Patrick Knecht]

Hello

We're using h2 db embbeded on our server application. The client
appliaction is available via share (read only!). Our Problem on client
side is the creation of the temp.db file(s) which happens when a
retrieved blob is above 65Kb. So h2 creates temp file on client's
execution directory which is read only (share in our case) and h2
throws execption (access denied, which is right) and data retrieval
fails.

We need to be able to define h2 temp file directory (like windows
temp where this {dedicated dir}/.db.lobs./{user}/1.temp.db goes to).

We tried with system properties h2.prefixTempFile and h2.baseDir but
expierenced no change in bevahior. Temp file creation still tried in
client's execurtion directory.

thanks for help
Patrick

[Kerry Sainsbury]

I'm no expert, but I took a quick look at the code and can see a method in FileSystemDisk called "createTempFile" that looks like it *could* be where the change is needed. There's a line that reads:

       if (inTempDir) {
            dir = null;

... I suspect you want it to be "dir = MY_TEMP_DIRECTORY" instead.

If you are have any Java experience you'll find the H2 code is pretty easy to work with and test. Give it a go!

Cheers
Kerry

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To post to this group, send email to h2-da...@googlegroups.com.
To unsubscribe from this group, send email to h2-database...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.

[Patrick Knecht]

Hi Kerry

Thanks for the answer. I went through the source I made adjustements
to ours need. We think this a bug. Client app can run from any program
folder which in vista or win7 has no write access, just
execution&read.

So if just blob come from server h2 db which is over 65kb so it will
create surely a temp file which lands in clients execution folder...
so bang, and access denied and no data.

h2.prefixTempFile and user.home seem to have no impact on client
side. Just traced it a bit, pls correct me if i'm wrong. We would be
even suggest that these parameters should be exposed as methods to
reset them during run in client side matters.

the method translateFileName in class FileSystemDisk takes mostly care
about these ''translations' which seems to be lot about substrings of
'~'. initTemp had not that impact as expected the settings via
properties could trigger.

We're really started to like h2 in our server client app, I made
really things around in order not to damage essential logic so only
adjust file path on client side's h2 lib.

I'd like really to do proposal for these so that we can switch again
on not adjusted main stream here ;-) Just over h2 in this matter in
our company so i'm bit green with it, but all thoughts are welcomed.

thanks,
Patrick

On Oct 6, 10:24 pm, Kerry Sainsbury <ke...@fidelma.com> wrote:
> I'm no expert, but I took a quick look at the code and can see a method in
> FileSystemDisk called "createTempFile" that looks like it *could* be where
> the change is needed. There's a line that reads:
>
>        if (inTempDir) {
>             dir = null;
>
> ... I suspect you want it to be "dir = MY_TEMP_DIRECTORY" instead.
>
> If you are have any Java experience you'll find the H2 code is pretty easy
> to work with and test. Give it a go!
>
> Cheers
> Kerry
>

> On Thu, Oct 7, 2010 at 1:45 AM, Patrick Knecht <pkne...@gmail.com> wrote:
> > Hello
>
> > We're using h2 db embbeded on our server application. The client
> > appliaction is available via share (read only!). Our Problem on client
> > side is the creation of the temp.db file(s) which happens when a
> > retrieved blob is above 65Kb.  So h2 creates temp file on client's
> > execution directory which is read only (share in our case) and h2
> > throws execption (access denied, which is right) and data retrieval
> > fails.
>
> > We need to be able to define  h2 temp file directory (like windows
> > temp where this {dedicated dir}/.db.lobs./{user}/1.temp.db goes to).
>
> > We tried with system properties h2.prefixTempFile and h2.baseDir but
> > expierenced no change in bevahior. Temp file creation still tried in
> > client's execurtion directory.
>
> > thanks for help
> > Patrick
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "H2 Database" group.
> > To post to this group, send email to h2-da...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > h2-database...@googlegroups.com<h2-database%2Bunsu...@googlegroups.com>
> > .

[Sergi Vladykin]

Hi,

The real problem is not in a place where h2 client stores temp blobs
but in the fact that it stores blobs to temp files at all. I think it
should not do this. It seems that it does this on each row fetch but
this is incorect since even if you have selected some result set
conatining blobs you are not necessarily will access this blobs but
they are all downloaded to the client machine. This can be ok if your
network is fast enough, blobs are not so big and you do not fetch too
many rows but if this is not the case you will have performance
problems. Also the write access problems you mention. So the right way
to fix this all is to get rid of temp blob files on client so that
result set will contain only some kind of links to remote blobs
instead of whole blob data.

regards,
S.Vladykin

[Thomas Mueller]

Hi,

The current behavior is bad of course. If temporary files are required
(they are currently) then they should be created in the temp
directory, and not in the current working directory. I will fix this
in the next release.

In the future, temporary files shouldn't be required at all. But this
will need more changes.

Regards,
Thomas