Транзакции JMS - накладные расходы - как этого избежать, если это возможно?

В нашем приложении мы получаем сообщения от JMS Topic.

  • Сначала я хочу знать, следует ли JMS политике FIFO. Если нет, то как приложение может решить, какое сообщение является последним?

Мы потребляем сообщения (постоянный подписчик и JMS-сеанс выполняются, много накладных расходов), потому что сообщения сохраняются на JMS-сервере до тех пор, пока транзакция не завершится/завершится. Причина, по которой мы указали транзакцию,

  • Мы используем технологию кэширования (гибернации) и транзакцию для ее использования. Итак, мы используем две транзакции: одна — JMS tx, а другая — технология кэширования. Когда мы потребляем сообщение и хотим, чтобы все или ничего не происходило, пока сообщение не будет зафиксировано и подтверждение не будет отправлено в JMS. кэширование tx будет зафиксировано первым, а затем сразу JMS tx будет зафиксировано следующим, и сообщение будет подтверждено, в противном случае оба tx будут отброшены, и сообщение будет воспроизведено. В настоящее время мы воспроизводим сообщения 3 раза, а затем, если исключение все еще возникает, мы отправляем сообщение в необрабатываемую очередь.

  • Это работает нормально до тех пор, пока в JMS одновременно не придет много сообщений, которые должны быть обработаны нашей системой одновременно.

  • Я хотел бы знать, что вы делали, когда столкнулись с таким сценарием. Потому что поддержание долговременной подписки и транзакционного сеанса требует значительных накладных расходов по сравнению с сервером JMS и снижает производительность сервера.


hibernate transactions jms spring-jms
person Community    schedule 03.04.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Порядок сообщений для тем не указан в спецификации JMS, поэтому официальный ответ на этот вопрос заключается в том, что это зависит от реализации JMS. Сказав это, если специально не переопределить что-то еще, я полагаю, что сообщения будут доставляться в порядке FIFO.

Что касается транзакций, я предлагаю вам изучить реализацию двухфазных транзакций XA фиксации, чтобы вам не нужны были две отдельные транзакции. Если ваша реализация кеша поддерживает XA, транзакции JMS и кеша (и БД) будут одним и тем же.

Как правило, я обнаружил, что для этих типов транзакционных сообщений, если вы должны использовать транзакционные сообщения, лучший способ снизить производительность — обработать как можно больше сообщений за одну транзакцию:

  1. Начать транзакцию
  2. Получить n сообщений (или все, пока не истечет время ожидания)
  3. Обрабатывать сообщения
  4. Зафиксируйте транзакцию.
  5. Go To 1.

Еще один способ убить двух зайцев одним выстрелом — пропустить обработку сообщения во время извлечения и просто записать полученные сообщения в хранилище транзакционных данных. Затем отдельный поток извлекает сообщения из хранилища (в порядке отметок времени) и обрабатывает их (отдельный поток - = отдельная транзакция).

person Nicholas    schedule 04.04.2012
comment
Ссылка: static.springsource.org/spring/docs/2.0. x/reference/ Чтобы настроить контейнер прослушивателя сообщений для участия в транзакциях XA, вам потребуется настроить JtaTransactionManager (который по умолчанию делегирует полномочия подсистеме транзакций сервера J2EE). Обратите внимание, что базовая JMS ConnectionFactory должна быть совместима с XA и должным образом зарегистрирована вашим координатором транзакций JTA! Это позволяет принимать сообщения, а также, например. доступ к базе данных должен быть частью одной и той же транзакции (с унифицированной семантикой фиксации за счет накладных расходов журнала транзакций XA). - person ; 04.04.2012
comment
и эта ссылка static.springsource.org/spring/docs/2.0 .x/reference/ С транзакциями Hibernate и JTA мы можем просто использовать JtaTransactionManager, как с JDBC или любой другой ресурсной стратегией. Означает ли это, что я могу использовать JtaTransactionManager вместо HibernateTxManager, который я сейчас использую? - person ; 04.04.2012
comment
Ты получил это. Но вам понадобится менеджер транзакций JTA, развернутый где-то весной. Если ваш контейнер Spring работает на полноценном сервере приложений (jboss, weblogic и т. д.), вам просто нужно сообщить Spring, где он находится. В противном случае вы можете развернуть его. Я нашел Arjuna (JBoss TX Manager) очень простым в настройке и развертывании в Spring. (См. community.jboss.org/wiki/JBossTransactionsWithSpring) - person Nicholas; 04.04.2012
comment
обязательно ли иметь транзакцию в JMS? В нашем приложении транзакции начинаются, когда JMS получает сообщение и обрабатывает несколько вставок и обновлений. Всякий раз, когда возникает исключение, он откатывает все изменения. Я не хочу откатывать все изменения. Так что все в порядке, если я удалю транзакцию из JMS? - person Vishal Patel; 08.07.2019