Safety of Thread.current[] usage in rails

I keep getting conflicting opinions on the practice of storing information in the Thread.current hash (e.g., the current_user, the current subdomain, etc.). The technique has been proposed as a way to simplify later processing within the model layer (query scoping, auditing, etc.).

• https://stackoverflow.com/questions/4217911/why-are-my-thread-variables-intermittent-in-rails
• https://stackoverflow.com/questions/7509883/alternative-to-using-thread-current-in-api-wrapper-for-rails
• https://stackoverflow.com/questions/6659221/are-thread-current-values-and-class-level-attributes-safe-to-use-in-rails

Many consider the practice unacceptable because it breaks the MVC pattern. Others express concerns about reliability/safety of the approach, and my 2-part question focuses on the latter aspect.

1. Is the Thread.current hash guaranteed to be available and private to one and only one response, throughout its entire cycle?

2. I understand that a thread, at the end of a response, may well be handed over to other incoming requests, thereby leaking any information stored in Thread.current. Would clearing such information before the end of the response (e.g. by executing Thread.current[:user] = nil from a controller's after_filter) suffice in preventing such security breach?

Thanks! Giuseppe

There is not an specific reason to stay away from thread-local variables, the main issues are:

• it's harder to test them, as you will have to remember to set the thread-local variables when you're testing out code that uses it
• classes that use thread locals will need knowledge that these objects are not available to them but inside a thread-local variable and this kind of indirection usually breaks the law of demeter
• not cleaning up thread-locals might be an issue if your framework reuses threads (the thread-local variable would be already initiated and code that relies on ||= calls to initialize variables might fail

So, while it's not completely out of question to use, the best approach is not to use them, but from time to time you hit a wall where a thread local is going to be the simplest possible solution without changing quite a lot of code and you will have to compromise, have a less than perfect object oriented model with the thread local or changing quite a lot of code to do the same.

So, it's mostly a matter of thinking which is going to be the best solution for your case and if you're really going down the thread-local path, I'd surely advise you to do it with blocks that remember to clean up after they are done, like the following:

around_filter :do_with_current_user

def do_with_current_user
    Thread.current[:current_user] = self.current_user
    begin
        yield
    ensure
        Thread.current[:current_user] = nil
    end      
end

This ensures the thread local variable is cleaned up before being used if this thread is recycled.

This little gem ensures your thread/request local variables not stick between requests: https://github.com/steveklabnik/request_store

The accepted answer covers the question but as Rails 5 now provides a "Abstract super class" ActiveSupport::CurrentAttributes which uses Thread.current.

I thought I would provide a link to that as a possible(unpopular) solution.

https://github.com/rails/rails/blob/master/activesupport/lib/active_support/current_attributes.rb

The accepted answer is technically accurate, but as pointed out in the answer gently, and in http://m.onkey.org/thread-safety-for-your-rails not so gently:

Don't use thread local storage, Thread.current if you don't absolutely have to

The gem for request_store is another solution (better) but just read the readme there for more reasons to stay away from thread local storage.

There is almost always a better way.