У меня есть приложение Spring Integration, где у меня есть адаптер входящего канала JMS, который будет получать сообщения из очереди в удаленном брокере JMS. Я ищу фабрику соединений непосредственно из удаленной службы JNDI брокера, и это то, что я использую для настройки моего адаптера входящего канала. Я понимаю, что за кулисами существует DefaultMessageListenerContainer. Согласно AbstractMessageListenerContainer javadocs, найдено здесь, если для параметра "sessionTransacted" установлено значение "true" для DMLC, локальные транзакции JMS будут использоваться для доставки сообщений от брокера.
Я не заинтересован в том, чтобы получение сообщений было частью транзакций, управляемых извне.
Теперь, если JMS-брокер предоставляет адаптер ресурсов и, следовательно, существует фабрика управляемых соединений JCA (которая может участвовать в транзакциях JTA), настроенная на сервере приложений JBoss, где моя Spring Integration работает в пакете war . Я мог бы использовать это вместо прямого просмотра JNDI брокера, как я описал выше. Поскольку меня не интересуют глобальные транзакции, я не вижу ценности использования этой фабрики соединений JCA, более того, я не знаю, может ли кэширование соединений/сеансов, которое делает JCA, конфликтовать со стратегией кэширования DMLC. Кроме того, я не уверен, что добавление слоя JCA для обертывания исходной фабрики соединений повлияет на производительность.
Каков правильный подход: взять фабрику соединений непосредственно у брокера JNDI и позволить DMLC обрабатывать все или взять соединение, управляемое JCA? Кажется, существует не очень хорошо задокументированная школа мысли, которая говорит, что JCA безопаснее и надежнее, но если я не использую EJB, я не понимаю, как это может быть правдой.
