As Thin/Unicorn are single threaded, how do you handle Thread.current/per-request storage?

Just ran a simple test - set a key in one session, read it from another -- looks like it writes/reads from the same place all the time. Doesn't happen on WEBrick though.

```
class TestController < ApplicationController
  def get
    render text: Thread.current[:xxx].inspect
  end

  def set
    Thread.current[:xxx] = 1

    render text: "SET to #{Thread.current[:xxx]}"
  end
end

```

Tried adding `config.threadsafe!` to application.rb, no change.

What's the right way to store per-request data?

How come there are gems (including Rails itself, and tilt) that use Thread.current for storage? How do they overcome this problem?

Could it be that Thread.current *is* safe per request, but just doesn't clear after request and I need to do that myself?

* Tested with Rails 3.2.9

Update
======

To sum up the discussion below with @skalee and @JesseWolgamott and my findings--

Thread.current depends on the server the app is running on. Though the server might make sure no two requests run at the same time on same Thread.current, the values in this hash **might not get cleared between requests**, so in case of usage - initial value must be set to override last value.

There are some well known gems who use Thread.current, like Rails, tilt and draper. I *guess* that if it was forbidden or not safe they wouldn't use it. It also seems like they all set a value before using any key on the hash (and even set it back to the original value after the request has ended).

But overall, Thread.current is not the best practice for per-request storage. For most cases, better design will do, but for some cases, use of `env` can help. It is available in controllers, but also in middleware, and can be injected to any place in the app.

**Update 2** - it seems that as for now, draper is uses Thread.current incorrectly. See <https://github.com/drapergem/draper/issues/390>

**Update 3** - that draper bug was fixed.