curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jozef Vilcek <>
Subject Persistent locks
Date Mon, 13 Jan 2014 14:19:58 GMT

I have a question about curator locks. I see that locks are implemented via
znode type EPHEMERAL_SEQUENTIAL. I am thinking about having an
implementation via PERSISTENT_SEQUENTIAL.

Main reason for this are processes with critical sections, where we can not
afford to loose a lock due to session expiration. In such case, others
might acquire a lock and kick in while the previous process is still
running but e.g. experiencing connection issues. To kill this temporally
detached process in favor of others would be too costly.

My thoughts are to have:

* Persistent lock - if something go south and client code does not release
lock, it will stay there until removed by manual or some other intervention

* Persistent ephemeral lock - this would be ephemeral implemented by
persistent lock. For not so much critical stuff but e.g. for unstable
environments. This would install kind of refresh hook on a created lock
node. Other clients waiting to acquire lock could garbage collect locks
which does not received refresh for reasonable long time (scaling beyond
session timeouts).

What I would like to know:

* any wisdom, if this does make sense or if there is a better way out there
* support from curator ... There is a lot of good code in curator I would
have to copy to make this work. I want to avoid this. Would it be possible
of provide either path for making locks core extensible/reusable (or to
contribute implementation of locks if considered worth for framework) ?


View raw message