Уровень кеширования компонентов Camel JMS и Spring CachingConnectionFactory

Question

Согласно документации Apache camel, мы должны установить уровень кэша на CACHE_CONSUMER, чтобы получить лучшую производительность при работе с транзакциями, отличными от XA. Вероятно, они это сделали, поскольку PooledConnectionFactory не кэширует потребителей.

Вместо PooledConnectionFactory я использую Spring CachingConnectionFactory, потому что PooledConnectionFactory - это то, что связано с ActiveMQ, а я имею дело с IBMMQ.

CachingConnectionFactory, с другой стороны, также кэширует производителей и потребителей. Так что я надеюсь, что в этом случае нет смысла устанавливать уровень кеширования JmsComponent на CACHE_CONSUMER.

Пожалуйста, поправьте меня, если я ошибаюсь. Любой совет будет большим подспорьем

Answer 1

Да, я чувствую, что ваше понимание прямо здесь.

Как сказано в одном из комментариев этого блога,

Хотя как PooledConnectionFactory и CachingConnectionFactory заявляют, что каждый из них объединяет соединения, сеансы и производителей, PooledConnectionFactoryфактически не создает кеш из нескольких производителей. Он просто использует одноэлементный шаблон для выдачи одного кэшированного производителя, когда он запрашивается. В то время какCachingConnectionFactory фактически создает кеш, содержащий несколько производителей, и выдает одного производителя из кеша по запросу.

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

Однако, используя CachingConnectionFactory, как описано в документации, кеширование потребителя и производителя по умолчаниюtrueа также при необходимости получить контроль над ними. Следовательно, уровень кэша больше не требуется.

Дополнительная помощь: Camel Docs

Answer 2

Добрый день,

Ваше понимание во многом верное. Обратите внимание, что когда вы применяетеCACHE_CONSUMERдля прослушивающего компонента это означает, что прослушиватель сообщений Spring JMS должен кэшировать получателя сообщения (что довольно очевидно). Кэширование потребителя требует, чтобы прослушиватель сообщений Spring JMS также кэшировал сеанс JMS и соединение.

Если вы хотите использовать конечную точку с транзакцией, ответственность за это кеширование нужно снять с прослушивателя сообщений Spring JMS. В случае транзакции вы экстернализируете фабрику кэширующих соединений. Вот почему уровень по умолчаниюCACHE_NONE если transacted является true.

Когда вы устанавливаете transacted к trueи предоставить фабрику соединений, создается менеджер транзакций JMS, который работает с фабрикой соединений для управления транзакциями. Вот почему прослушиватель сообщений Spring JMS не может управлять потребителем / сеансом / соединением.

Первый ответ правильный, используя CachingConnectionFactoryобеспечит вам кеширование, которое вы хотите, а также выведет кеширование из контейнера прослушивателя сообщений Spring. Это позволяет менеджеру транзакций иметь доступ к сеансу JMS.