A proposal for more reliable locks using Redis
1–10 of 27 posts
Re: A proposal for more reliable locks using Redis
#2So the locks in a Distributed version work something like the NRW concept in Riak ?
Re: A proposal for more reliable locks using Redis
#3So the locks in a Distributed version work something like the NRW concept in Riak ?
The algorithm described more closely resembles a CP system (in its need to successfully lock the majority of instances), since it requires majority to be available and in order to lock a resource. Also it is not a tunable algorithm, at least the majority of nodes must be locked in order for the safety to be guaranteed.
Re: A proposal for more reliable locks using Redis
#4It seems like a lock should be able to autorelease in a distributed environment if the acquirer is no longer available. Would this not be considered "safe?"
What about broadcasting acquire/release messages?
Re: A proposal for more reliable locks using Redis
#5It seems like a lock should be able to autorelease in a distributed environment if the acquirer is no longer available. Would this not be considered "safe?" What about broadcasting acquire/release messages?
The proposed algorithm provides a safety guarantee which is time bound: once the lock is acquired it has a specified validity time, after this time, it is possible for another client to reacquire it.
In practical terms this forces you to have the protected code path to be "real time", which is, guaranteed to terminate (or to abort) without the specified time.
Re: A proposal for more reliable locks using Redis
#6It seems like a lock should be able to autorelease in a distributed environment if the acquirer is no longer available. Would this not be considered "safe?" What about broadcasting acquire/release messages?
The proposed algorithm provides a safety guarantee which is time bound: once the lock is acquired it has a specified validity time, after this time, it is possible for another client to reacquire it. In practical terms this forces you to have the protected code path to be "real time", which is, guaranteed to terminate (or to abort) without the specified time.
It seems like a timeout is less reliable/safe than some broadcast/ping mechanism that can check availability perpetually and if a node has disappeared the validity of the lock changes.
Trying to remember which distributed system model it is that sort of does this. Ring? Mesh?
Re: A proposal for more reliable locks using Redis
#7Earlier quoted context omitted.
The proposed algorithm provides a safety guarantee which is time bound: once the lock is acquired it has a specified validity time, after this time, it is possible for another client to reacquire it. In practical terms this forces you to have the protected code path to be "real time", which is, guaranteed to terminate (or to abort) without the specified time.
It seems like a timeout is less reliable/safe than some broadcast/ping mechanism that can check availability perpetually and if a node has disappeared the validity of the lock changes. Trying to remember which distributed system model it is that sort of does this. Ring? Mesh?
For such a model to work I believe you need a distributed replicated state machine, and the clients to be an active part of the distributed system (not just participating doing requests), being able to reply to pings. Yes, there is a safety advantage in the model you describe, as if the time taken to finish with an operation is larger than expected, the other clients may want to wait more, but in the practice:
1) What you do if the client replies to pings but takes an apparently never ending time to perform the operation on the shared resource?
2) What about if the client is correctly operating on the shared resource but the only component which is failing is the system you use to check its availability?
Re: A proposal for more reliable locks using Redis
#8I wrote a very similar, Redis-based lock in Python a while ago, here it is:
https://gist.github.com/adewes/6103220
It uses Redis pipelines and watchers to make sure that no race conditions between two processes requiring the same lock occur, and uses "expire" keys to avoid deadlocks.
Re: A proposal for more reliable locks using Redis
#9Earlier quoted context omitted.
It seems like a timeout is less reliable/safe than some broadcast/ping mechanism that can check availability perpetually and if a node has disappeared the validity of the lock changes. Trying to remember which distributed system model it is that sort of does this. Ring? Mesh?
For such a model to work I believe you need a distributed replicated state machine, and the clients to be an active part of the distributed system (not just participating doing requests), being able to reply to pings. Yes, there is a safety advantage in the model you describe, as if the time taken to finish with an operation is larger than expected, the other clients may want to wait more, but in the practice: 1) Wha…
1) I think a mix of the two approaches would work here - an actual timeout to a lock but not the only way of keeping a lock
2) I suppose that's always possible, but then what would happen is the lock would be released. Not ideal behavior but also not one that presents a data reliability issue.
Re: A proposal for more reliable locks using Redis
#10It seems like a lock should be able to autorelease in a distributed environment if the acquirer is no longer available. Would this not be considered "safe?" What about broadcasting acquire/release messages?
The proposed algorithm provides a safety guarantee which is time bound: once the lock is acquired it has a specified validity time, after this time, it is possible for another client to reacquire it. In practical terms this forces you to have the protected code path to be "real time", which is, guaranteed to terminate (or to abort) without the specified time.
>In practical terms this forces you to have the protected code path to be "real time", which is, guaranteed to terminate (or to abort) without the specified time.
You could keep re-acquiring the lock when it gets close to expiring, and stop your process if the lock becomes un-acquirable.