New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
propose implementation of extend #20
Conversation
# also https://github.com/sbertrang/redis-distlock/issues/2 which proposes the value-checking | ||
EXTEND_SCRIPT = <<-eos | ||
if redis.call( "get", KEYS[1] ) == ARGV[1] then | ||
if redis.call( "set", KEYS[1], ARGV[1], "XX", "PX", ARGV[2] ) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "XX"
is not needed here as the line before made sure the key exists.
Instead of carrying around your extend
variable through the various lock
methods, I'd suggest combining the SETNX
command for lock and the extend script into one:
def lock(resource, ttl, extend: {}, &block)
value = extend[:value] || SecureRandom.uuid
lock_info = try_lock_instances resource, ttl, value
[...]
end
LOCK_SCRIPT = <<-eos
if redis.call("exists",KEYS[1]) == 0 or redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("set",KEYS[1],ARGV[1],"PX",ARGV[2])
end
eos
[...]
Executing a script for lock()
each time is presumable worse in terms of performance than a SETNX
command, but I'd still prefer this for readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@antirez do you prefer always calling a script or choosing between a script and SETNX?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seamusabshere Thinking about it, unifying it into a single script sure changes the semantic of the algorithm, as "extending" could become a combination of "lock extended" (i.e. lock was still there with our value
) and "new lock set" (key was expired). Not sure about the consequences though.
@seamusabshere Unfortunately I can't provide you any input on algorithm correctness, hope @antirez can help us out here. |
|
@leandromoreira Sure why not |
e09f327
to
1847a39
Compare
cf4f5dd
to
70b3524
Compare
@antirez You have any comments on this? Do we violate any guarantees with this? @leandromoreira Otherwise, should we proceed and merge this? I'm pretty sure the patch does not change anything to the original algorithm as long as one's not using |
@maltoe I agree but let's wait a week to see if @antirez comments anything otherwise we merge. Thanks @seamusabshere and sorry to make you wait so long |
thanks to @seamusabshere and @maltoe =) |
@seamusabshere I tried to merge but github states:
|
Please see #24 |
per @antirez this needs a theoretical review - would @maltoe and/or @leandromoreira or @antirez himself help me with that?
thanks to @sbertrang for original perl implementation https://github.com/sbertrang/redis-distlock and @biancalana for value-checking sbertrang/redis-distlock#2