On Fri, 24 Sep 2004, Matt Sergeant wrote:

On 24 Sep 2004, at 17:43, Ara.T.Howard wrote:

On Fri, 24 Sep 2004, Matt Sergeant wrote:

On 24 Sep 2004, at 14:51, Ara.T.Howard wrote:

What are people's views on this?
i think it's sufficiently common to merit discussion on best practices at
least.

More than that, I'm thinking there might be a call for an os_nfs.c that uses this NFS clean locking mechanism.

which nfs clean locking mechanism? AFAIK there is not one that works across
the platforms sqlite supports.

The link() one you use. Some of us don't care about cross platform if we can hack in something guaranteed to work on NFS.

ah. well - lockfile exists on linux bug is slightly buggy and does not give great performance. my program and apis are simply improved ruby version of the algorithim desribed in the lockfile man page. i have verified with the nfs developers that this approach is guarunteed to be atomic. the lockfile code is publicly available, c, and quite simple. it would be easy to use it. as i said before though - this does not give you any sort of read lock. if you don't care about portability (i don't either) then using and empty file and applying fcntl locks (read or write) to it seems like the best approach since

  - sqlite already will require fcntl locks on *nix
  - gives read/write lock types
  - someone else maintains the code
  - nfs locking will be even better in v4 (lease based)

using this an the external locking mechanism would simply mean adding a hook
to lock a sentinal file with a write lock any time a byte range lock would
normally be done in the api - else apply a read lock for all other operations.

this simple approach give nfs safe multiple reader single writer access on
nfs in an mostly portable fashion.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. | --Dogen
===============================================================================

Reply via email to