Спецификация сервлета 3 и ThreadLocal

Насколько мне известно, спецификация сервлета 3 вводит функцию асинхронной обработки. Среди прочего, это будет означать, что один и тот же поток может и будет повторно использован для обработки другого, одновременный, HTTP-запрос (ы). Это не революционно, по крайней мере, для людей, которые раньше работали с NIO.

В любом случае, это приводит к еще одной важной вещи: no ThreadLocal переменные как временное хранилище для запроса данные. Потому что, если тот же поток внезапно становится потоком-носителем для другого HTTP-запроса, локальные данные запроса будут открыты для другого запроса.

Все это мои чистые предположения, основанные на чтении статей, у меня нет времени играть с любыми реализациями Servlet 3 (Tomcat 7, GlassFish 3.0.X и т. д.).

Итак, вопросы:

• Правильно ли я предполагаю, что ThreadLocal перестанет быть удобным средством для хранения данных запроса?
• Кто-нибудь играл с какой-либо из реализаций сервлета 3 и пробовал использовать ThreadLocal ] s, чтобы доказать вышесказанное?
• Помимо хранения данных внутри HTTP-сеанса, вы могли бы посоветовать еще какие-нибудь подобные легкодоступные уловки?

РЕДАКТИРОВАТЬ: не поймите меня неправильно. Я полностью понимаю опасности и ThreadLocal взлома. Фактически, я всегда советую не использовать его в подобном контексте. Однако, хотите верьте, хотите нет, контекст потока использовался гораздо чаще, чем вы думаете. Хорошим примером может служить Spring OpenSessionInViewFilter , который, согласно его Javadoc:

Этот фильтр делает Hibernate Sessions Я полностью понимаю опасности и ThreadLocal взлома. Фактически, я всегда советую не использовать его в подобном контексте. Однако, хотите верьте, хотите нет, контекст потока использовался гораздо чаще, чем вы думаете. Хорошим примером может служить Spring OpenSessionInViewFilter , который, согласно его Javadoc:

Этот фильтр делает Hibernate Sessions Я полностью понимаю опасности и ThreadLocal взлома. Фактически, я всегда советую не использовать его в подобном контексте. Однако, хотите верьте, хотите нет, контекст потока использовался гораздо чаще, чем вы думаете. Хорошим примером может служить Spring OpenSessionInViewFilter , который, согласно его Javadoc:

Этот фильтр делает Hibernate Sessions доступно через текущий поток, который будет автоматически обнаружен менеджеры транзакций.

Это не совсем ThreadLocal (не проверял источник), но уже звучит тревожно. Я могу придумать более похожие сценарии, и обилие веб-фреймворков делает это намного более вероятным.

Короче говоря, многие люди построили свои замки из песка на основе этого хака, осознавая или не осознавая этого. Поэтому ответ Стивена понятен, но не совсем то, что мне нужно. Я хотел бы получить подтверждение, действительно ли пробовал и смог воспроизвести неудачное поведение, чтобы этот вопрос можно было использовать в качестве ориентира для других, попавших в ловушку той же проблемы.