Unlock all servers if lock could not be acquired. #5
Conversation
In case a SETNX command was indeed received by a Redis server but the response did not make it through, we should still try to unlock it in case the quorum can not be reached or TTL is up. See: antirez/redlock-rb#3
|
About the remaining questions in the issue above: Not sure if we want to go that way. Aborting in case the TTL is used up ( |
|
Cool @maltoe, I think we should avoid complexity right now. Btw what's your rubygem user? @antirez asked you to link the redlock-rb to Redlock page, I'm 100% agree with that. 🍰 "@maltoe I see you are contributing to a fork of this lib, I guess what you are developing is more an usable lib compared to my proof of concept, right? Is it a good idea to link it from the Redlock page? Thanks." |
|
@leandromoreira rubygem user is 'maltoe', but most of my ruby work is under 'flavoursys' |
|
@maltoe looking at http://guides.rubygems.org/command-reference/#gem-owner how to add a gem owner I saw that in fact I need your email. |
|
malte dot rohde at flavoursys dot com should work |
|
@leandromoreira Btw, if you're ok with the merge requests of today, I'm going to just put them on top of master to avoid pointless merge commits |
|
@maltoe go ahead, and if you want you can also bump up version, I already added you as gem owner. |
This reverts my change to only unlock servers that reported successful SETNX commands, as indicated in the algorithm description.
antirez/redlock-rb#3