Low commit activity in last 3 years
A long-lived project that still receives updates
RequestLocals gives you per-request global storage in Rails
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
 Dependencies

Development

~> 5.0
>= 0

Runtime

 Project Readme

RequestLocals

Gem Version CI Code Coverage Maintainability License

If you have ever needed to use a global variable in Rails, you know it sucks.

One common solution is the awesome request_store:

def self.foo
  RequestStore.fetch(:foo) { 0 }
end

def self.foo=(value)
  RequestStore.store[:foo] = value
end

The problem

request_store scopes values to the execution context handling the request. When work moves to another thread, that thread accesses a different store.

The solution

Add this line to your Gemfile:

gem 'request_store_rails'

And change the code to this:

def self.foo
  RequestLocals.fetch(:foo) { 0 }
end

def self.foo=(value)
  RequestLocals.store[:foo] = value
end

Everywhere you used RequestStore.store, change it to RequestLocals.store. Now your variables will actually be stored in a true request-local way.

Multi-Threading

The middleware stores each request's context in ActiveSupport::IsolatedExecutionState, the same mechanism used by Rails' CurrentAttributes. Existing RequestLocals usage automatically follows the thread or fiber isolation level configured by Rails, without application changes.

When explicitly spawning a new thread, propagate the current store id with RequestLocals.set_current_store_id so the new thread can access the same request-local values.

A good way to apply this pattern is by encapsulating it into a helper class:

# Public: Custom thread class that allows us to preserve the request context.
class ThreadWithContext

  # Public: Returns a new Thread that preserves the context of the current request.
  def ThreadWithContext.new(*args)
    store_id = RequestLocals.current_store_id
    Thread.new {
      RequestLocals.set_current_store_id(store_id)
      yield *args
    }
  end
end

RequestLocals[:foo] = 1

ThreadWithContext.new {
  puts RequestLocals[:foo] # => 1
}

The gem does not provide such construct to avoid name collisions, you are free to reuse the snippet above and adjust it to match your use case.

If you are feeling adventurous, you could try using this fire and forget script and make all of your threads request aware, or should I say prepend and forget ๐Ÿ˜„? Probably not something to be used in a production environment, but whatever floats your boat โ›ต

Atomicity

Have in mind that the RequestLocals.fetch(:foo) { 'default' } operation is atomic, while RequestLocal[:foo] ||= 'default' is not. In most scenarios, there is not a lot of difference, but if you are in a concurrent environment make sure to use the one that is more suitable for your use case ๐Ÿ˜‰

Replacing request_store

While the plan is not to achieve 100% compatibility, this gem usually works well as a drop-in replacement. If you are using gems that rely on RequestStore but for some reason you need them to use the appropriate request/thread scope, you can try something like this on application.rb or similar:3

if RequestStore != RequestLocals
  RequestStore::Railtie.initializers.clear
  Kernel.suppress_warnings { RequestStore = RequestLocals }
end

Usage in Sidekiq

If your code depends on these global variables, it's likely that you'll need to avoid collisions in Sidekiq workers (which would happen if the current store id is nil).

You can use the following middleware, using the job id to identify the store:

class Sidekiq::Middleware::Server::RequestStoreRails
  def call(_worker, job, _queue)
    RequestLocals.set_current_store_id(job['jid'])
    yield
  ensure
    RequestLocals.clear!
    RequestLocals.set_current_store_id(nil)
  end
end

Make sure to configure it as server middleware:

Sidekiq.configure_server do |config|
  config.server_middleware do |chain|
    chain.add Sidekiq::Middleware::Server::RequestStoreRails
  end
end

Special Thanks

The inspiration for this gem, tests, and a big part of the readme were borrowed from the really cool request_store gem. Thanks Steve ๐Ÿ˜ƒ

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Don't forget to run the tests with rake.

License

Copyright (c) 2015 Mรกximo Mussini

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.