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

Question

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

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

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

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

Answer 1

Добрый день,

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

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

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

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

Answer 2

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

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

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

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

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

Дополнительная помощь: Документы верблюда