Вопрос по java – Использование ThreadLocal в корпоративном приложении

13

Если мое веб-приложение и приложение ejb находятся на одной машине (на одной и той же JVM), и все вызовы ejb являются локальными вызовами, будет ли использоватьсяThreadLocal создавать какие-либо проблемы при передаче информации из Интернета в EJB?

Любой обходной путь, если вызовы ejb являются удаленными? БудетThreadLocal информация будет доступна из веб-приложения в приложение EJB? Является ли использованиеThreadLocal желательно в таком сценарии?

Ваш Ответ

7   ответов
1

all the ejb calls are local calls , will the use of ThreadLocal create any issue while

Нет, ты сам ответил на свой вопрос. Поскольку вызовы локальны, они выполняются в контексте одного потока.

Any workaround if the ejb calls are remote?

В случае удаленных вызовов контейнер Java EE будет запущен в другой JVM, он создаст свои собственные потоки для обработки входящего запроса RMI, для удаленного контейнера Java EE нет способа узнать о локальных переменных потока, которые были объявлены в Обратная сторона. Передайте его как объект параметра.

0

ThreadLocal не может использоваться со 100% уверенностью в веб-приложениях. У вас просто нет гарантии, что один поток будет использоваться для одного сеанса. С моей точки зрения, это может быть очень трудно найти дыру в безопасности!

ctx.getContextData() у меня не работает, всегда возвращаетсяnull!

Я тоже пробовалTransactionSynchronizationRegistry, но я получаюnull также.

Единственное, что сработало, - это использование JAAS в качестве обходного пути. Но это не очень хорошее решение.

2

При использовании EJB 3.1 вы можете передавать контекстную информацию вEJBContext используя егоконтекстные данные, Это простоMap<String,Object>.

0

Это зависит от того, какую информацию вы передаете! Первый вопрос это слишком общий. Я предлагаю прочитать JavaDoc, связанный с ThreadLocalВот.

ThreadLocal работает на стороне сервера приложения и используется для обеспечения безопасности вызовов Thread ваших объектов Thread.

Error: User Rate Limit Exceeded
2

ThreadLocal не должен использоваться в контекстах EJB. Нельзя гарантировать, что все вызовы EJB-метода находятся в одном потоке (конечно, так и должно быть).

В EJB есть другой подходTransactionSyncrhonizationRegistry, УвидетьОбъяснение / Использование для дальнейших деталей.

0

Для местных звонковThreadLocal должно работать нормально, если все сделано в одном потоке.

Для удаленных вызовов, которые могут потенциально выполняться на другом сервере, вам нужно придумать что-то еще. Либо передайте все значения в качестве параметров (которые будут работать, но привносят сложность в код), либо используйте что-то вроде распределенного кэша, напримерHazelcast, который будет функционировать как глобальныйHashMap, к которому имеют доступ все узлы кластера.

14

По первому вопросу проблем нет, если вы удаляете переменные ThreadLocal в конце каждого вызова. Это важно, потому что контейнеры (сервлет или ejb) обычно используют пулы потоков и поэтому повторно используют потоки, это имеет два эффекта: один & quot; call & quot; может видеть информацию о локальном потоке, полученную из предыдущего вызова, и если вы удалите приложение из контейнера, не останавливая JVM, некоторые классы могут не быть сборщиком мусора, поскольку на них все еще ссылается поток контейнера. Поэтому поместите данные в локальный поток в блоке try / finally и удалите его в элементе finally.

Вот пост, показывающий один из способов решения проблемы:ThreadLocal в веб-приложениях

Что касается второго вопроса, поскольку данные являются локальными по потоку, они не будут поступать с удаленным вызовом, вы должны добавить параметр в свои интерфейсы, извлечь данные с локальным потоком с одной стороны и воссоздать их с другой стороны ...

Error: User Rate Limit Exceeded Snake Eye
Error: User Rate Limit Exceeded Snake Eye

Похожие вопросы