The way I see it we have two choices: either we need something that can be created and then destroyed on exit aka the deleteOnExit file -The only objection of heard to this so far is that H2 doesn't support it. Is their a reason that we can't make H2 do it? or could we look at other disk cache options?
or We could enforce a unique home directory for each client where it's data is stored. - is their a way to make this not a pain for users? Lets go into this assuming the problem can and will be solved. On Mar 29, 2008, at 6:51 AM, Geert Bevin wrote: > We've had problems with sticking the db in a temp directory, some > files on Gary's machine that were needed for the db's proper working > were removed on Windows while the application was still running. > That's one of the reasons his first demo failed. > > Apart from all that, this really is a product choice, as any approach > is of course possible and I'm just talking from my preference. I > however have to say that I have a strong aversion against applications > that create new files by default on every run in a non predictable > location. > > On Thu, Mar 27, 2008 at 6:50 PM, Steven Harris <[EMAIL PROTECTED] > > wrote: >> We can't hack H2 to do this? and stick everything in the default tmp >> directory for the os? >> >> >> >> On Mar 27, 2008, at 6:41 PM, Geert Bevin wrote: >> >>> Don't think so since the db files are created by H2 and not by us >>> and >>> there can be any number of files created for indexes, temp queries, >>> etc etc. >>> >>> On Thu, Mar 27, 2008 at 6:19 PM, Steven Harris <[EMAIL PROTECTED] >>>> wrote: >>>> I disagree but I'll live with it. BTW, java has a kind of file the >>>> deletes on exit of the JVM doesn't it? Can >>>> we adjust the db to use that and then use the unique names? >>>> >>>> >>>> >>>> On Mar 27, 2008, at 6:16 PM, Geert Bevin wrote: >>>> >>>>> We can, but I prefer not because that would defer any problems >>>>> with >>>>> creating the db until the time that people actually need to >>>>> capture >>>>> statistics. Usually when that is the case, you don't want to >>>>> have to >>>>> start restarted clients and such to make sure that the database >>>>> can be >>>>> created. >>>>> >>>>> On Thu, Mar 27, 2008 at 5:45 PM, Steven Harris <[EMAIL PROTECTED] >>>>>> wrote: >>>>>> Just out of curiosity. When do we create the db. Can we wait to >>>>>> do it >>>>>> until someone does snapshotting? >>>>>> >>>>>> >>>>>> On Mar 27, 2008, at 5:40 PM, Geert Bevin wrote: >>>>>> >>>>>>> Since otherwise at each execution it creates a new version of >>>>>>> the >>>>>>> embedded database structure. >>>>>>> >>>>>>> On Thu, Mar 27, 2008 at 4:58 PM, Taylor Gautier >>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>> Why would it need to be repeatable? >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Geert Bevin" <[EMAIL PROTECTED]> >>>>>>>> To: [email protected] >>>>>>>> Sent: Thursday, March 27, 2008 4:42:21 PM (GMT-0800) America/ >>>>>>>> Los_Angeles >>>>>>>> Subject: Re: [tc-dev] need to standardize on the system >>>>>>>> property >>>>>>>> names >>>>>>>> >>>>>>>> >>>>>>>> It's unique, but not repeatable. I think this is ok for the >>>>>>>> demos, >>>>>>>> but >>>>>>>> not ok for regular applications since it creates a new >>>>>>>> directory at >>>>>>>> each execution. >>>>>>>> >>>>>>>> On Thu, Mar 27, 2008 at 4:36 PM, Taylor Gautier <[EMAIL PROTECTED] >>>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> So just to add color to this issue - the samples use the >>>>>>>>> following >>>>>>>>> convention: >>>>>>>>> >>>>>>>>> <logs>%(user.home)/terracotta/client-logs/pojo/sharededitor/ >>>>>>>>> %D</logs> >>>>>>>>> >>>>>>>>> %D is a unique value. >>>>>>>>> >>>>>>>>> >>>>>>>>> Geert Bevin wrote: >>>>>>>>> >>>>>>>>> I wasn't suggesting which property should be used. My point is >>>>>>>>> that it >>>>>>>>> should be the same and I do agree that it would be handy to >>>>>>>>> have >>>>>>>>> some >>>>>>>>> >>>>>>>>> I agree with that, I was just clarifying why I chose the >>>>>>>>> tc.node- >>>>>>>>> name >>>>>>>>> syntax and not tc.nodeName. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> kind of node discovery in place instead of using system >>>>>>>>> properties. >>>>>>>>> BTW, Maven property been there for over half a year and no one >>>>>>>>> reporter this inconsistency. >>>>>>>>> >>>>>>>>> I don't know what you mean by setup differently, all I see is >>>>>>>>> that >>>>>>>>> if >>>>>>>>> I remove <statistics> elements from tc-config those dirs are >>>>>>>>> created in >>>>>>>>> the current folder, at least when this stuff is run from >>>>>>>>> Maven. >>>>>>>>> >>>>>>>>> I just tried this and it seems to behave like that for the >>>>>>>>> client >>>>>>>>> log >>>>>>>>> dirs too. So it seems that when the logs and statistics >>>>>>>>> elements >>>>>>>>> are >>>>>>>>> removed, the default values in the xsd aren't being applied. >>>>>>>>> This >>>>>>>>> needs some further investigation. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Also it is really odd, that even if I specify different >>>>>>>>> locations >>>>>>>>> for >>>>>>>>> those stats folders I still see that huge warning about >>>>>>>>> directory is >>>>>>>>> already being used when launching L1 and L2 from Maven. >>>>>>>>> >>>>>>>>> I tried that with the distribution samples and when I change >>>>>>>>> the >>>>>>>>> client and server statistics paths, they relocate properly to >>>>>>>>> what I >>>>>>>>> set them to. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> tc-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Geert Bevin >>>>>>>> Terracotta - http://www.terracotta.org >>>>>>>> Uwyn "Use what you need" - http://uwyn.com >>>>>>>> RIFE Java application framework - http://rifers.org >>>>>>>> Music and words - http://gbevin.com >>>>>>>> _______________________________________________ >>>>>>>> tc-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> tc-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Geert Bevin >>>>>>> Terracotta - http://www.terracotta.org >>>>>>> Uwyn "Use what you need" - http://uwyn.com >>>>>>> RIFE Java application framework - http://rifers.org >>>>>>> Music and words - http://gbevin.com >>>>>>> _______________________________________________ >>>>>>> tc-dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>> >>>>>> _______________________________________________ >>>>>> tc-dev mailing list >>>>>> [email protected] >>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Geert Bevin >>>>> Terracotta - http://www.terracotta.org >>>>> Uwyn "Use what you need" - http://uwyn.com >>>>> RIFE Java application framework - http://rifers.org >>>>> Music and words - http://gbevin.com >>>>> _______________________________________________ >>>>> tc-dev mailing list >>>>> [email protected] >>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>> >>>> _______________________________________________ >>>> tc-dev mailing list >>>> [email protected] >>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>> >>> >>> >>> >>> -- >>> Geert Bevin >>> Terracotta - http://www.terracotta.org >>> Uwyn "Use what you need" - http://uwyn.com >>> RIFE Java application framework - http://rifers.org >>> Music and words - http://gbevin.com >>> _______________________________________________ >>> tc-dev mailing list >>> [email protected] >>> http://lists.terracotta.org/mailman/listinfo/tc-dev >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev >> > > > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Music and words - http://gbevin.com > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
