Транзакции JMS - накладные расходы - как избежать этого, если это возможно? - PullRequest
0 голосов
/ 03 апреля 2012

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

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

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

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

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

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

1 Ответ

1 голос
/ 04 апреля 2012

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

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

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

  1. Начать транзакцию
  2. Получение n сообщений (или всех их до истечения времени ожидания)
  3. Обработка сообщений
  4. Совершить транзакцию.
  5. Перейти к 1.

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

...