сообщение JMS Driven Bean синхронизации работник

Question

Мы только начинаем строить нашу JMS архитектуру и имеют следующие основные настройки:

1. GlassFish v2.1
2. MDB прослушивания на тему через TopicConnectionFactory (все на местном сервер)

Теперь MDB нерестится рабочий поток при поступлении нового сообщения и даже если мы имеем в доставке заказа сообщений, нам нужен механизм синхронизации таким образом, чтобы потоки проверить определенное состояние, прежде чем одновременно обрабатывать запрос ,

Есть ли способ для этих потоков обмениваться данными? Или существуют ли какие-либо другие механизмы (кроме таблиц базы данных/строк), которые мы можем использовать для синхронизации?

Заранее спасибо.

---

Чтобы уточнить, я не создаю свои темы. Как все правильно отметили, контейнер делает это для меня. Позвольте мне объяснить пример моей дилеммы.

-Message поступает при Т = 0, который «создает» идентификатор данных 1

-Message В прибывающий при Т = 0,1, какие данные «обновления» идентификатор 1

Теперь предполагая контейнера Spawns 2 рабочих к процесс A & B, и для создания «данных» требуется гораздо больше времени, чем обновление, обновление будет обрабатываться раньше и не будет иметь эффекта.

Чтобы быть более ясным,

-Хотя Обработка сообщений B, я искал бы ид данных 1 при Т = 1 (не найти его и, таким образом, имеют отделку, ничего не делая).

-Данный идентификатор 1 будет создан при обработке сообщения A при t = 2.

Answer 1

Я не понимаю, почему MDB должен порождать рабочий поток. В JMS есть пул потоков, связанный с прослушивателями сообщений. Это поток, который должен выполнять эту работу.

Спецификация EJB говорит, что в вашей фасоли не существует нити. Контейнер обрабатывает резьбу. Это включает также MDB.

Слушатель должен обрабатывать сообщение, в котором он снимает очередь. Необходимые данные должны быть в сообщении. Что нужно для обмена?

Я думаю, что ваш подход противоречит рекомендациям EJB.

Answer 2

Предупреждение о педанте! Я такой парень, который читает фактические спецификации технологий.

Чтение EJB spec версия 3.0, раздел 21.1.2 (Ограничения программирования) запрещает использование потоков в коде. Вот язык и обоснование ...

Компонент предприятия не должен использовать для управления потоками.Фирм предприятия не должен пытаться запустить, остановить, приостановить или возобновить поток, или изменить приоритет или имя потока. Компонент предприятия не должен использовать команду для управления группами потоков.

Эти функции зарезервированы для контейнера EJB. Разрешение предприятия bean для управления потоками уменьшало бы способность контейнера правильно управлять средой выполнения.

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

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

Answer 3

Как уже упоминалось выше, структура JMS обрабатывает такие проблемы, как диспетчерские потоки. Все, что вы делаете в этом случае, будет не только уступать по умолчанию, он, вероятно, будет сильно ограничивать функциональность вашей JMS.

Более сложные обработчики JMS предназначены для работы на нескольких узлах (= серверах), поэтому любое решение общей памяти ограничит вас одной JVM на одном узле, что было бы очень жалко, поскольку большое преимущество JMS - это масштабируемость ,

Возможное решение JMSy заключается в том, что очередь «cookie» будет иметь одно фиктивное сообщение «cookie», чтобы синхронизировать действия. Когда пришло время для вашего процесса для выполнения спорного деятельности он «получает с ожиданием» в одном сообщении из очереди «куки», когда спорная работа завершена он помещает печенье обратно в очередь. Магия JMS будет обрабатывать почти все блокирование, ожидание и восстановление ошибок.

Answer 4

Как уже упоминалось несколькими людьми, вы не должны создавать свои собственные потоки в MDB (или любом другом типе EJB или сервлете, если на то пошло).

Многие контейнеры EJB на самом деле не позволят вам создавать и запускать потоки. Есть один безопасный способ сделать это, хотя, используя WorkManager из спецификации commonj, хотя я не вижу причин для этого в этом конкретном случае, поскольку MDB уже работает в своем собственном «рабочем потоке».

Дополнительную информацию см. В разделе info on spawning threads here: почему вы не должны создавать потоки на сервере Java EE и как сделать это безопасно, когда вам нужно.

Answer 5

Похоже, что вопрос полностью изменился в природе после того, как все уже ответили на него. Я буду очень запоздалым ответом для потомков; это предполагает, что существует некоторый тип идентификатора сообщения, который можно использовать для заказа. Вы говорите: «У нас есть порядок доставки сообщений», но вы точно не знаете, как это достигается.

... Поскольку вы выяснили, что вы не начинаете свои собственные темы, у вас в основном есть условие гонки между «созданием» данных @ ID = 1 и последующим «обновлением». Я предполагаю, что вы блокируете данные @ ID = 1 во время создания и/или обновления. Итак, есть две возможности:

1. сообщение «создать данные» приходит первым: (1) блокировка ID = 1, (2) создать данные. (3) отпустите замок. (4) применить ожидающее «обновление».
2. «обновление» до «создания»: (1) блокировка ID = 1, (2) создать недостающие данные (т. Е. Выполнить «повышение»: вставить данные, даже если их нет). (3) отпустите замок. (4) игнорировать ожидающее сообщение «создать данные» (сообщение «создать» имеет более низкий порядковый номер, чем «обновление»
   • Если отправителю сообщения разрешено отправлять обновления и вставлять одновременно (без запроса/ответа) , то они действительно должны иметь какой-то порядковый номер. Если это так, когда приходит «вставка», его порядковый номер будет меньше текущего значения в этой строке, поэтому его можно игнорировать. Или, если сообщение «создать» тип отличается от «обновления» тип сообщения, то «создает» всегда можно пренебречь, если уже существует данных.

Я думаю, что вопрос у вас есть, как Synchr onize по данным. По сути, потоки совместно используют объекты и создают мьютекс (взаимное исключение), чтобы позволить одному потоку получать доступ к данным, заставляя другой поток блокироваться. Это можно сделать просто через низкоуровневые средства синхронизации Java (ключевое слово «synchronized») или встроенные классы, которые помогают с этим (http://java.sun.com/docs/books/tutorial/essential/concurrency/highlevel.html).

Answer 6

Настоящая проблема заключается в том, что сервер приложений обычно порождает упомянутых рабочих отдельно. Хотя JMS гарантирует, что сообщения потребляются в том же порядке, в каком они производятся, по крайней мере, внутри одного производителя, спецификация MDB явно заявляет, что заказ не сохраняется (из-за упомянутых работников). См. Раздел 5.4.11 от JSR-000220 Enterprise JavaBeans 3.0 Final Release (ejbcore).

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

К счастью, большинство серверов приложений имеют способы, хотя и запатентованы и несовместимы, настроить количество рабочих.

Для JBoss и ActiveMQ это работает:

@PoolClass(value = org.jboss.ejb3.StrictMaxPool.class, maxSize = 1) 
@MessageDriven(activationConfig = { 
    @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), 
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
    @ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "1"), 
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "TEST.FOO") 
}) 
@ResourceAdapter("activemq-ra.rar") 
public class NewMessageBean implements MessageListener { ... } 

В этом случае "maxSessions" являются количество рабочих. Это может быть другим с другими поставщиками JMS, но это должно указывать на правильное направление.