Если мое веб-приложение и приложение ejb находятся на одном компьютере (на одной JVM) и все вызовы ejb являются локальными вызовами, не создаст ли использование ThreadLocal каких-либо проблем при передаче информации из Интернета в ejb?
Любое обходное решение, если вызовы ejb удалены? Будет ли информация ThreadLocal доступна из веб-приложения в приложение ejb? Целесообразно ли использование ThreadLocal в таком сценарии?
Для первого вопроса нет проблем, если вы удаляете переменные ThreadLocal в конце каждого вызова. Это важно, потому что контейнеры (сервлет или ejb) обычно используют пулы потоков и, следовательно, повторно используют потоки, это имеет два эффекта: один «вызов» может видеть информацию о потоке, поступающую от предыдущего вызова, и если вы удаляете приложение из контейнера без остановки JVM некоторые классы могут не подвергаться сборке мусора, поскольку на них по-прежнему ссылается поток контейнера. Поэтому поместите данные в threadlocal в блоке try/finally и удалите в части finally.
Вот сообщение, показывающее один из способов решения проблемы: ThreadLocal в веб-приложениях
Что касается второго вопроса, поскольку данные являются локальными для потоков, они не будут выполняться с удаленным вызовом, вам нужно добавить параметр в свои интерфейсы, извлечь локальные данные для потоков с одной стороны и воссоздать их с другой стороны...
При использовании EJB 3.1 вы можете передавать контекстную информацию в EJBContext с использованием его контекстных данных. Это всего лишь Map<String,Object>.
ThreadLocal не следует использовать в контексте EJB. Нельзя гарантировать, что все вызовы методов EJB находятся в одном и том же потоке (конечно, так и должно быть).
В EJB используется другой подход, называемый TransactionSyncrhonizationRegistry. См. Объяснение/Использование для получения дополнительной информации.
все вызовы ejb являются локальными вызовами, создаст ли использование ThreadLocal какие-либо проблемы, в то время как
Нет, вы сами ответили на свой вопрос. Поскольку вызовы являются локальными, они выполняются в контексте одного потока.
Любое обходное решение, если вызовы ejb удалены?
В случае удаленных вызовов контейнер Java EE будет запущен в другой JVM, он будет порождать свои собственные потоки для обработки входящего запроса RMI, удаленный контейнер Java EE не может знать о локальных переменных потока, которые были объявлены на Обратная сторона. Передайте его как объект параметра.
Это зависит от того, какую информацию вы передаете! Первый вопрос слишком общий. Я предлагаю прочитать JavaDoc, связанный с ThreadLocal здесь.
ThreadLocal живет на стороне сервера приложения и используется для того, чтобы обеспечить безопасность вызовов ваших объектов Thread.
Для локальных вызовов ThreadLocal должен работать нормально, если все выполняется в одном потоке.
Для удаленных вызовов, которые потенциально могут выполняться на другом сервере, вам нужно будет придумать что-то еще. Либо передайте все значения в качестве параметров (что будет работать, но усложнит код), либо используйте что-то вроде распределенного кеша, например. Hazelcast, который будет функционировать как глобальный HashMap, к которому имеют доступ все узлы кластера.
ThreadLocal нельзя использовать со 100% уверенностью в веб-приложениях. У вас просто нет гарантии, что один поток будет использоваться для одного сеанса. С моей точки зрения, это может стать очень трудно найти дыру в безопасности!
ctx.getContextData() у меня не работает, всегда возвращает null!
Я также пробовал TransactionSynchronizationRegistry, но также получаю null.
Единственное, что сработало, это использование JAAS в качестве обходного пути. Но это не очень хорошее решение.
