Re: [htdig-dev] Help required with "configure" - Porting Adjustable Logging Patch to 3.2

[Geoff H. <ghu...@ws...>]

On Thu, 12 Sep 2002, Brian White wrote:

> Well, all except the "until they have granularity" bit -
> what does that mean?

In theory, we can do multi-write to the databases by locking *parts* of
the database, rather than the full file. This would be through the
Berkeley DB code and would obviously make file locking obsolete.

> 1) What do we do about "dangling" locks? ( where
>     lock files get left behind due to a crash or some
>     other kind of bug)

I think we'd want some sort of timeout. Using PIDs wouldn't help the
typical problem, which is running multiple programs on the same file. Yes,
out-of-sync clocks are a problem, but if we pick a long enough timeout and
document the behavior (so sysadmins can kill the lockfiles if there are
problems) it should be OK.

> 2) If locks have to be valid across machines, the
>     TMPDIR isn't going to work unless it is explicitly
>     put into a common area?

True. Of course the rundig scripts typically set TMPDIR to the database
directory, but you're right that we can't count on this.

> 3) Also - do locks need to work between different
>     programs? What if they have different
>     permissions

>     Another solution is to use the process id - but that

No, I don't think we want locks to be tied to the PID. The same PID is
already prevented from opening the same file twice--you'd need to have two
copies of DocumentDB, etc.

--
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/