Skip to content

Conversation

alex88
Copy link

@alex88 alex88 commented Mar 19, 2016

This is something that hopefully helps me solve #22.
Basically it lets the user add a safe guard in case the process that has acquired the lock dies (e.g. due SIGKILL) by being able to renew the lock expiration to a later time. I imagine the usage to be:

# Create the mutex with a very low expire time, this is useful so in case the process dies, the mutex isn't
# locked for more than 10 seconds (in a long process as in my case the mutex is locked for 5
# minutes so in case of process failure it generates a very long delay)
mutex = RedisMutex.new(:test_lock, :expire => 10, :block => 0)
mutex.with_lock do
  data_to_be_processed.each do |row|
    make_external_request(row) # Hopefeully this takes less than 10 seconds
    mutex.reset_expire                # Get another 10 seconds to work on the next row
  end
end

let me know if it's something you're interested in, in that case maybe the get+set has to be done in a single redis transaction and I should also add some docs in the readme. Otherwise I'll just keep the fork for our project


# Extends the expire time just in case process needs more time
def reset_expire
raise ExpireResetError, "extend_expire should be called only on locked resources" unless locked?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should check the ownership of the lock by get == @expires_at.to_s instead of just locked?

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.

2 participants