Skip to content
Pessimistic locking using Redis
Branch: master
Clone or download
Latest commit 08f1bb5 Mar 16, 2016
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
lib
spec
test Change redis.lock signature to have timeout as a named option (acquire) Feb 7, 2012
.gitignore
.rspec minor rspec formatting Jan 23, 2012
.travis.yml fixes name of redis package Aug 30, 2012
Gemfile Clean up Gemfile Aug 25, 2013
Gemfile-redis2
Gemfile-redis2.lock Version bump to 0.2.3 Jun 19, 2013
Gemfile-redis3
Gemfile-redis3.lock
Guardfile Add rspec, simplecov, guard Jan 22, 2012
LICENSE Autogenerated code. Jan 22, 2012
README.md
Rakefile minor cleanup Jan 22, 2012
redis-lock.gemspec Version bump for: bug fix. Oct 22, 2015

README.md

Redis::Lock

Build Status

This gem implements a pessimistic lock using Redis. It correctly handles timeouts and vanishing lock owners (such as machine failures)

This uses setnx, but not the setnx algorithm described in the redis cookbook, which is not robust.

Installation

Add this line to your application's Gemfile:

gem 'mlanett-redis-lock', require: 'redis-lock'

And then execute:

$ bundle

Or install it yourself as:

$ gem install mlanett-redis-lock

Background

A lock needs an expected lifetime. If the owner of a lock disappears (due to machine failure, network failure, process death), you want the lock to expire and another owner to be able to acquire the lock. At the same time, the owner of a lock should be able to extend its lifetime. Thus, you can acquire a lock with a conservative estimate on lifetime, and extend it as necessary, rather than acquiring the lock with a very long lifetime which will result in long waits in the event of failures.

A lock needs an owner. Redis::Lock defaults to using an owner id of HOSTNAME:PID.

A lock may need more than one attempt to acquire it. Redis::Lock offers an acquisition timeout; this defaults to 10 seconds.

There are two lock methods: Redis#lock, which is more convenient, and Redis::Lock#lock. Notice there are two timeouts: the lock's lifetime (:life option) and the acquisition timeout, which is less important. The acquisition timeout is set via the :acquire option to Redis#lock or passed directly to Redis::Lock#lock.

Usage

This gem adds lock(), locked?() and unlock() to Redis instances.

lock() takes a block and is safer than using lock() and unlock() separately. lock() takes a key and lifetime and optionally an acquisition timeout (defaulting to 10 seconds).

redis = ::Redis.connect
redis.lock("test") { |lock| do_something }

redis.lock("test", life: 2*60, acquire: 2) do |lock|
  array.each do |entry|
    do_something(entry)
    lock.extend_life(60)
  end
end

locked?() checks if lock is already acquired. It takes key argument, which you have used with lock() function earlier.

redis = ::Redis.connect
redis.lock("test") { |lock| do_something }

if redis.locked?("test")
  puts "work in progress"
end

Goals

I wrote this when noticing that other lock gems were using non-robust approaches.

You need to be able to handle race conditions while acquiring the lock. You need to be able to handle the owner of the lock failing to release it. You need to be able to detect stale locks. You need to handle race conditions while cleaning the stale lock and acquiring a new one. The code which cleans the stale lock may not be able to assume it gets the new one. The code which cleans the stale lock must not interfere with a different owner acquiring the lock.

Contributors

Alexander Lang (langalex), Jonathan Hyman (jonhyman), Jamie Cobbett (jamiecobbett), Ravil Bayramgalin (brainopia), and Tom Mornini (tmornini) have contributed to Redis Lock.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request
You can’t perform that action at this time.