Rosenberg, Eric wrote:
>I think there may be some downsides to storing the log file in a different
>location then the main file.
>- Doesn't this increase the chance for name collisions on the system? With
>the current scheme as long as 2 apps are running in different portions of
>the file system they can use the same database name. If you start storing
>the log file in the temp directory then you would run into trouble if 2
>programs running on the same machine both tried to open a record manager
Use File.createTempFile(..) and it's not a problem.
>- If I want to copy the data file from one machine to another now I'm going
>to have to know to go find the temp directory on the particular machine that
>I'm copying from and to get the log file as well. If I'm accessing the data
>directory over the network I may not even have access to the temp directory
>where the log file is.
The whole point of the sync-tx-log was that you'd only have to deal with
the .db file. This is in the case that you programmatically know when
files are being copied/backuped, but IMHO you'd want that anyway for
>- I don't think you can make any assumptions about when the contents of a
>temp directory are deleted. If my application crashes and the temp directory
>contents are deleted then I lose all the data in the log file.
I've never experienced that a temp file is deleted without me doing it.
What OS are you concerned with?
>- With the current scheme if I'm using a remote directory as my data
>directory I can start my application on any machine that can see the same
>directory (not at the same time of course). If the log file is moved to the
>temp directory then only the machine where the application was first started
>will be able to access the log file.
If it's configurable it shouldn't be an issue.
>Admittedly none of these are very strong arguments, but I don't see the
>benefit in making the change. Is it just so that you see one less file when
>doing an 'ls' in the directory?
It's good not having to bother with files that shouldn't have to be
bothered with. Iff the log can be explicitly flushed it becomes one such
We're currently using Jisp and every time we want to move the database
we essentially have to zip up the files instead of just moving it. If
there's only one file there's less reason for using zip to make moving
the data easier.
>Personally, I think I'd rather see the log
>file remain in the same directory as the database file.
Which is why it should be configurable.
>I'd like to know
>that jdbm is storing all its data in the location I told it to.
Well, it is. The log file isn't really the data. It's just a temporary
internal file for running it.
>separating them is going to needlessly add a level of complexity.
And to me it's the opposite, i.e. it reduces complexity since there's
one less file to bother with.
But YMMV, so making it configurable, with the default being as it is
already, should be the right way to go.