branch locking mk2.

[Nir Soffer]

Check MoinMoin/util/lock.py, which has similar but simpler design using  
only directories. Its about having one write lock or multiple read  
locks per resource.

  *  
http://arch.thinkmo.de/cgi-bin/archzoom.cgi/arch@arch.thinkmo.de--2003- 
archives/moin--main--1.3--patch-935/MoinMoin/util/lock.py
  *  
http://arch.thinkmo.de/cgi-bin/archzoom.cgi/arch@arch.thinkmo.de--2003- 
archives/moin--main--1.3--patch-935/MoinMoin/_tests/test_util_lock.py

Sorry about those archish urls :-)

On 8 Feb, 2006, at 2:11, Robert Collins wrote:

> Martin mentioned doing a new lock type on list a few days back, I have
> chatted with him about that, and his ideas. The follow is a brain dump
> of that for discussion and what we think would be nice for discussion,
> critique etc.
>
>
> A side note, but an important one : this cannot simply replace the
> existing locks, we need to keeo the current lock code for compatibility
> with extant clients. It requires a format change to each object that
> uses this to introduce it.
>
>
> The desired characteristics are:
> * Locks are not reentrant
> * Stale locks can be guessed at by a heuristic
> * Lost locks can be broken by any client
> * Failed lock operations leave little or no mess
> * Deadlocks are avoided by having a timeout always in use, clients
> desiring indefinite waits can retry or set a silly big timeout.
>
>
> Proposed implementation [this is a sketch - details subject to
> refinement (and tweaked from what we discussed as I realised some minor
> issues while typing)]:
> where a lock called 'foo' is desired, we make a directory:
> foo/
>
> which always has subdirs pending and released:
> foo/
> foo/pending/
> foo/released/
>
> and if the lock is current held an owner:
> foo/
> foo/locked/details.txt
> foo/pending/
> foo/released/
>
> To take out a lock, make a temporary dir with a random name in pending,
> and write a lock object to details.txt in that dir using the 'rio'
> format. Details that are required are 'name', 'time' and possibly
> hostname/pid. Then rename that temporary dir to foo/locked.
>
> To remove the lock rename the directory locked to
> foo/released/temporary-name, and then delete the details.txt and the
> random dir name.
>
> This is robust - AFAWK on all fs's directory renames are atomic and you
> cannot get two competing successes. If we are worried that we can get
> that, we can read details.txt to ensure its the right one.
>
> If a pending lock is removed the rename into the lock dir fails, so
> pruning noise in the pending dir is safe.
>
> Similarly a communications error during lock release will at most
> prevent it being released (the rename fails), or prevent cleanup after
> its released, in which case everything in released/ can be considered
> temp files to be removed whenever they are noticed.
>
> Stale locks can be guessed at by the datestamp on the file if the  
> server
> has one, or the datestamp in the details.txt rio output.
>
> A possible future enhancement would be to add a 'last-used.txt' file as
> a heartbeat, to enhance the reliability of stale lock detection, but
> Martin thinks this is not needed for a first cut of the system, and I
> agree.
>
> Performance wise taking a lock is three roundtrips:
> mkdir
> write details.txt
> rename
>
> and releasing is also three roundtrips:
> rename
> rm details.txt
> rmdir
>
>
> Thoughts?
> Rob
>
>
>
> -- 
> GPG key available at: <http://www.robertcollins.net/keys.txt>.
>

Best Regards,

Nir Soffer