branch locking mk2.

[John A Meinel]

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.

reentrant --- meaning the client itself deals with reentrance, rather
than the lock itself. (Like it is currently done).

I like the 'create a dir in pending, rename it to locked' portion of
your proposal.
But I don't know what 'released' gives you. Other than being able to
determine *after the fact*, that someone broke your lock. I suppose that
is important, but by then, the data is probably corrupted (better than
not knowing it was corrupted, I guess).

Anyway, it seems like quite a bit of work, that still doesn't handle
true transactions. I think the pending=>locked is good, locked=>released
seems like extra work that doesn't help much.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/91ea51c4/attachment.pgp