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/ ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
