I have a Spring Integration application, where I have a JMS inbound channel adapter that will receive messages from a queue in a remote JMS broker. I'm looking up the connection factory directly from the broker's remote JNDI service and this is what I use to set up my inbound channel adapter. I understand that behind the scenes there is a DefaultMessageListenerContainer. According to AbstractMessageListenerContainer javadocs, found here, if "sessionTransacted" is set to "true" for the DMLC, local JMS transactions will be used for the delivery of messages from the broker.
I'm not interested in having the receipt of messages to be part of externally managed transactions.
Now, if the JMS broker provides a resource adapter and therefore there is a JCA managed connection factory (that might be capable of participating in JTA transactions) configured in a JBoss App server where my Spring Integration is running packaged in a war . I could use this instead of directly looking up from the broker's JNDI as I described above. Since I am not interested in global transactions, I don't see the value of using this JCA connection factory, moreover I don't know if the caching of connections/sessions that JCA does might clash with the DMLC caching strategy. Additionally I'm not sure if adding a JCA layer to wrap the original connection factory will impact performance.
Which is the right approach then, take connection factory directly from broker JNDI and let DMLC handle everything or take a JCA managed connection? There seems to be a not very well documented school of thought that tells that JCA is safer and more robust, but if I'm not using EJBs I dont see how this can be true.
