branch locking mk2.

[Jan Hudec]

On Wed, Feb 08, 2006 at 23:23:41 +1100, Robert Collins wrote:
> On Wed, 2006-02-08 at 14:11 +0200, Nir Soffer wrote:
> 
> > I don't see how you can change the timeout after a caller got a lock. 
> > The caller can safely assume he has a lock for the full timeout.
> 
> ....
> I think our lock designs are solving quite different problems. The
> design I started this thread with is intended to work across the network
> on exceeding dumb and unfriendly file systems, it requires few
> properties of the file system (specifically it requires that renaming a
> directory to a directory fails, and that renaming a directory is atomic,
> and that files can be stored in directories and are moved when their
> containing directory is renamed). Note that it does not require that
> creating files or directories is atomic.
> 
> From what you say the moin locks are not applicable to our issues here
> because:
>  * we cannot kill other processes over the network, 
>  * we cannot share instance variables with other lock holders
>  * we cannot be sure that creating a directory can only succeed for one
> caller.
> 
> The way the design [which has had no negative feedback yet, fingers
> crossed] works is very similar to arch locks, a refinement on them
> perhaps. One
>  *  creates a directory with a probabilistically unique name (so
> atomicity of create does not matter),
>  * writes a data file inside the directory (atomicity does not matter as
> competing lockers are not hostile and will not alter the inside of
> directories that are not their own; if they were to want to gc pending
> locks they would rename the dir before rmming to cause failures if the
> locker was still active.)
>  * peforms a rename of the directory to a known location, this will fail
> on all platforms we know about if there is a destination file; its this
> failure that we want and that makes the locking logic safe.
> 
> Unlocking is just done in reverse, but to a different temporary
> location. 

There is this one issue that the locking does not solve, though. In
Arch, the lock directory was used as a staging area. So breaking it
actually destroyed the data prepared there, so the lock could always be
safely broken. Ie. it was really a transaction.

Now bzr still needs the ability to break stale locks -- with no safe way
to recognize a stale lock. Therefore it IMHO needs a way to make sure
the repository does not break even if it accidentaly breaks a non-stale
lock. Which the locking scheme by itself does not solve.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/2f1aa13e/attachment.pgp