ThreadLocal безопасность в пуле потоков Weblogic

Question

Я пишу приложение, которое использует MDB, EJB и нуждается в ThreadLocal для передачи и регистрации переменной между несколькими EJB и классами Helper до завершения транзакции.

Поток

Начиная с MDB onMessage () -> некоторые бизнес-делегаты EJB -> некоторые помощники

Вопрос:

Это приложение работает в Weblogic, и Weblogic повторно использует потоки из своего ThreadPool. Так есть ли вероятность повреждения данных между потоками? Является ли решение для использования ThreadLocal.remove() достаточно безопасным?

Есть ли альтернатива ThreadLocal, кроме передачи объекта в качестве параметра всем методам?

Answer 1

WebLogic не сбрасывает заданные пользователем переменные ThreadLocal при возврате потока обратно в пул - пользователь отвечает за их управление.Когда такие потоки используются повторно, вероятно, они будут мешать.Вы можете столкнуться с утечками памяти, так как локальная ссылка на поток не очищена.Вы можете безопасно сбросить свои локальные потоки до возврата потока обратно в контейнер.Вызов ThreadLocal.remove () должен очистить его (убедиться, что он выполнен в блоке finally)

Обратите внимание, что если задействованы какие-либо асинхронные или rmi-вызовы, локальные потоки не будут распространяться.Возможно, вы захотите рассмотреть функцию WebLogic WorkArea, которая позволяет распространять контекст между потоками, клиентами и серверами.Более подробную информацию можно найти на http://download.oracle.com/docs/cd/E17904_01/web.1111/e13706/context.htm#i1058690

Answer 2

Вы не можете надежно использовать ThreadLocal на уровне EJB.Даже если ваш код кажется «работающим» сейчас, что произойдет, если кто-то развернет один из ваших компонентов?От Ограничения EJB :

Почему запрещено создание потоков и управление ими?

Спецификация EJB возлагает на контейнер EJB ответственностьуправление потоками.Разрешение экземплярам корпоративного компонента создавать потоки и управлять ими может повлиять на способность контейнера управлять жизненным циклом его компонентов.Управление потоками - это не бизнес-функция, это деталь реализации, обычно сложная и зависящая от платформы.Разрешение контейнера управлять потоками освобождает разработчика корпоративных бинов от решения проблем потоков.Многопоточные приложения все еще возможны, но управление многопоточностью находится в контейнере, а не в корпоративном компоненте.

Если вам нужно совместно использовать состояние, вы должны передать его методу EJB в качестве параметра,Есть ли причина, по которой этот подход не будет работать для вас?Другой вариант - временно сбросить его в базу данных или кэш, включенный в транзакцию.

Answer 3

@ JoseK: хотя я не пробовал то, что вы описали в своей проблеме, но вот мои мысли: -

1. И MDB, и Session-бины являются поточно-ориентированными. Это означает, что, скажем, если есть пул из 10 бинов, только 10 запросов будут обрабатываться одновременно. Другие запросы будут поставлены в очередь на свою очередь. Поэтому локальные данные одного запущенного потока не должны мешать другому потоку.

2. Если вы уверены, что будете использовать локальные EJB-компоненты всегда в будущем, то я не вижу никаких проблем в использовании локальных данных потоков. Потому что вы на самом деле не создаете темы.

3. Хотя weblogic предоставляет поток из пула потоков, но этот поток выделяется специально для каждого потока запросов, я не думаю, что его локальные данные должны быть повреждены.

4. Как я уже сказал, я не пробовал сам, что я попробую: -

В слое MDB (ваш первый слой), выполните Thread.getCurrentThread.setName (name) и в последующих слоях выведите имена потоков, например Thread.getCurrentThread.getName)

Выполнение нескольких запусков с различным размером пула ejb, пула потоков. Присвойте другое имя потока каждому потоку запросов. Попробуйте выполнить несколько запросов одновременно. И посмотри, получишь ли ты когда-нибудь смешанное имя потока.

5. Сказав выше, чтобы упростить задачу и обеспечить дальнейшую поддержку EJB, я бы также передавал интерфейс CallingContext каждому слою.