Врожденные опасности использования переменных ThreadLocal с EJB3?

Question

Я экспериментирую с решением для авторизации и аутентификации, сохраняя предметный класс в карте ThreadLocal.Дизайн для API, поэтому у меня не будет доступа к задействованным сервлетам, и мне нужно использовать EJB3 (поэтому CDI не вариант).У меня есть несколько вопросов об использовании ThreadLocal с EJB3

1. Предполагая, что каждый запрос очищает свою карту ThreadLocal после того, как это сделано, есть ли риск при использовании переменной ThreadLocal с сеансными компонентами без состояния?Другими словами, есть ли риск, что два запроса получат доступ к одному и тому же потоку одновременно?

2. Существует ли какой-либо способ принудительного применения сервлетов к очистке ThreadLocal после их выполнения??Я изучил перехватчики, но понял, что они плохо работают с EJB3 и работают по-разному на разных серверах приложений.Любым другим путем?

Answer 1

Что касается ответа Мартина, стоит отметить, что Spring Security в любом случае по умолчанию использует ThreadLocal ( SecurityContextHolder ), поэтому я буду осторожен с его использованием, если вам нужен контекст безопасности для выживания при вызовах EJB,Конечно, это не будет работать через удаленные вызовы;это может быть с локальным, но я не думаю, что есть какие-либо гарантии.

Как правило, при использовании Spring Security я избегаю EJB и использую Spring Framework для подключения среднего уровня POJO и для предоставления услуг, таких как разграничение транзакций черезАОП.В этом случае контекст безопасности становится доступным на всем среднем уровне, поскольку поток остается неизменным на протяжении всего вызова.

Answer 2

Чтобы ответить на мой собственный вопрос, нет, не похоже на какую-либо безопасность. Использование переменной локального потока может работать, если у меня есть контроль над всем процессом, но если бы я это сделал, я мог бы использовать CDI или JSP для сохранения локальных переменных запроса.

Указывает на всех, кто ответил, хотя.

Answer 3

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