title: Safety of Thread.current[] usage in rails
body: <p>I keep getting conflicting opinions on the practice of storing information in the <code>Thread.current</code> 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.). </p>
  
  <ul>
  <li><a href="https://stackoverflow.com/questions/4217911/why-are-my-thread-variables-intermittent-in-rails">Why are my thread variables intermittent in Rails?</a></li>
  <li><a href="https://stackoverflow.com/questions/7509883/alternative-to-using-thread-current-in-api-wrapper-for-rails">Alternative to using Thread.current in API wrapper for Rails</a></li>
  <li><a href="https://stackoverflow.com/questions/6659221/are-thread-current-values-and-class-level-attributes-safe-to-use-in-rails">Are Thread.current[] values and class level attributes safe to use in rails?</a></li>
  </ul>
  
  <p>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.</p>
  
  <ol>
  <li><p>Is the <code>Thread.current</code> hash guaranteed to be available and private to one and only one response, throughout its entire cycle?</p></li>
  <li><p>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 <code>Thread.current</code>. Would clearing such information before the end of the response (e.g. by executing <code>Thread.current[:user] = nil</code> from a controller's <code>after_filter</code>) suffice in preventing such security breach?</p></li>
  </ol>
  
  <p>Thanks!
  Giuseppe</p>