Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

seamusabshere
Copy link
Contributor

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

# 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
Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

@maltoe
Copy link
Collaborator

maltoe commented Sep 8, 2015

@seamusabshere Unfortunately I can't provide you any input on algorithm correctness, hope @antirez can help us out here.

@leandromoreira
Copy link
Owner

off topic: should we release a new version @maltoe ?

@maltoe
Copy link
Collaborator

maltoe commented Sep 10, 2015

@leandromoreira Sure why not

@maltoe
Copy link
Collaborator

maltoe commented Oct 1, 2015

@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 extend.

@leandromoreira
Copy link
Owner

@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

@leandromoreira
Copy link
Owner

thanks to @seamusabshere and @maltoe =)

@leandromoreira
Copy link
Owner

@seamusabshere I tried to merge but github states:

This branch has conflicts that must be resolved

@maltoe maltoe mentioned this pull request Oct 7, 2015
@maltoe
Copy link
Collaborator

maltoe commented Oct 7, 2015

Please see #24

@maltoe maltoe closed this Oct 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants