Open Stack

Excerpts from Matthew Booth's message of 2014-06-17 01:36:11 -0700:
> On 17/06/14 00:28, Joshua Harlow wrote:
> > So this is a reader/write lock then?
> > 
> > I have seen https://github.com/python-zk/kazoo/pull/141 come up in the
> > kazoo (zookeeper python library) but there was a lack of a maintainer for
> > that 'recipe', perhaps if we really find this needed we can help get that
> > pull request 'sponsored' so that it can be used for this purpose?
> > 
> > 
> > As far as resiliency, the thing I was thinking about was how correct do u
> > want this lock to be?
> > 
> > If u say go with memcached and a locking mechanism using it this will not
> > be correct but it might work good enough under normal usage. So that¹s why
> > I was wondering about what level of correctness do you want and what do
> > you want to happen if a server that is maintaining the lock record dies.
> > In memcaches case this will literally be 1 server, even if sharding is
> > being used, since a key hashes to one server. So if that one server goes
> > down (or a network split happens) then it is possible for two entities to
> > believe they own the same lock (and if the network split recovers this
> > gets even weirder); so that¹s what I was wondering about when mentioning
> > resiliency and how much incorrectness you are willing to tolerate.
> 
> From my POV, the most important things are:
> 
> * 2 nodes must never believe they hold the same lock
> * A node must eventually get the lock
> 

If these are musts, then memcache is a no-go for locking. memcached is
likely to delete anything it is storing in its RAM, at any time. Also
if you have several memcache servers, a momentary network blip could
lead to acquiring the lock erroneously.

The only thing it is useful for is coalescing, where a broken lock just
means wasted resources, erroneous errors, etc. If consistency is needed,
then you need a consistent backend.