curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jozef Vilcek <>
Subject Re: Persistent locks
Date Tue, 14 Jan 2014 08:18:15 GMT
Yes, you are correct. I tried to sketch this in my post. There will be
possibility to create persistent lock, which will cause deadlock if holder
crashes and one with possibility to to be gc collected after some time if
holder crashes. The mechanism for this has to be implemented.

Off course that I use "classical" ephemeral locks where possible. But I
have few cases where it is not feasible.

On Tue, Jan 14, 2014 at 2:42 AM, Jordan Zimmerman <> wrote:

> How will you avoid dead locks? You’ll need to write some kind of
> heartbeat/gc mechanism to the lock. Otherwise I don’t see how it works if
> the lock holder crashes.
> -JZ
> ------------------------------
> From: Jozef Vilcek Jozef Vilcek <>
> Reply:
> Date: January 13, 2014 at 7:24:06 AM
> To:
> Subject:  Persistent locks
>  Hi
> 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) ?
> Best,
> Jozo

View raw message