Is there any difference between CachingConnectionFactory configured to have cache bigger than 1 and PoolingConnectionFactory?
I have seen both in various projects and I would like to understand the rationale behind choosing one of them.
It really depends on your use case.
The bittronix factory pools connections and serves up a different connection for each use (and returns it to the pool).
The CachingConnectionFactory uses a single connection and caches sessions, producers, consumers.
That really is a strange question. Do you need XA? If yes, then you have no choice but to go with PoolingConnectionFactory. You don't need XA? Then don't bother with Bitronix and go with CachingConnectionFactory.
If you use plugable XA transaction managers like Bitronix (or Atomikos), use their pool implementations instead of Spring's because they perform additional operations like automatic enlisting in of resources in XA transactions.
Bitronix pools are:
bitronix.tm.resource.jdbc.PoolingDataSource for JDBC
bitronix.tm.resource.jms.PoolingConnectionFactory for JMS
It's worth to take a look at the Bitronix test cases for examples how to setup the pools:
https://github.com/bitronix/btm/blob/master/btm/src/test/java/bitronix/tm/mock/JmsPoolTest.java
https://github.com/bitronix/btm/blob/master/btm/src/test/java/bitronix/tm/mock/JdbcPoolTest.java
Related
Is there an equivalent to the ActiveMQ 5 PooledConnectionFactory for Artemis? Why is it available in one and not the other?
Spring, for example, offers a generic CachingConnectionFactory. This is great, but it implements the SingleConnectionFactory and only "pools" one connection.
It would be key to have a similar mechanism in the Artemis client that actually pooled greater than one connections.
Another thought is that maybe it's not implemented because a single connection supports concurrent sessions! I haven't tested the performance of a using a new connection per session. Is the performance the same or similar?
The PooledConnectionFactory in the ActiveMQ 5.x code-base is generic and can actually be used with ActiveMQ Artemis so there was no reason to port it into the Artemis code-base. That said, the JMS connection pool implementation has been pulled out of the ActiveMQ 5.x code-base, cleaned up, modified to support JMS 2, and made available here.
I'm not clear on what you mean by "concurrent sessions." Do you mean that the connection supports concurrently creating session or that the sessions themselves support concurrent use? The former is supported, but the latter is not.
In terms of performance, you'd have to benchmark your specific use-case. There are too many variables to simply say one is better than the other.
from Spring documentation(http://docs.spring.io/spring/docs/current/spring-framework-reference/html/transaction.html):
16.2.1 Global transactions
Global transactions enable you to work with multiple transactional
resources, typically relational databases and message queues. The
application server manages global transactions through the JTA, which
is a cumbersome API to use (partly due to its exception model).
Furthermore, a JTA UserTransaction normally needs to be sourced from
JNDI, meaning that you also need to use JNDI in order to use JTA.
Obviously the use of global transactions would limit any potential
reuse of application code, as JTA is normally only available in an
application server environment.
Previously, the preferred way to use global transactions was via EJB
CMT (Container Managed Transaction): CMT is a form of declarative
transaction management (as distinguished from programmatic transaction
management). EJB CMT removes the need for transaction-related JNDI
lookups, although of course the use of EJB itself necessitates the use
of JNDI. It removes most but not all of the need to write Java code to
control transactions. The significant downside is that CMT is tied to
JTA and an application server environment. Also, it is only available
if one chooses to implement business logic in EJBs, or at least behind
a transactional EJB facade. The negatives of EJB in general are so
great that this is not an attractive proposition, especially in the
face of compelling alternatives for declarative transaction
management.
For me it looks like distributed transaction description(XA).
Am I wrong or Spring really calls XA tranactions as global.
I am using WebSphere with ActiveMQ and ActiveMQ's JCA adapter. In our application, there are a lot of queues for different functionalities. So can you tell me, should I create one ConnectionFactory for each queue(functionality) or only one ConnectionFactory for the whole application and shared for the queues ? And the reason.
Thanks in advance.
Really depends what are your requirements. It is not specific to ActiveMQ, but queuing in general. You usually may create separate connection factories when you have:
different host/port for different queues
different security credentials to connect
want to have different connection pools
So for example, if you want to ensure that at least n connections are available for certain queues you can create separate connection factory for that. As with one connection factory, in some extreme cases, when most of your application load is - let say - on functionalityA queues, then you may not have enough connections for your functionalityB queues and that functionality may suffer starving.
I've been doing some research(here and here and etc.) and with some experience I have follwing feeling about the choice between the two, it seems like:
CachingConnectionFactory is for simple container that don't have much of messaging transaction management(like Tomcat with ActiveMQ), so that the caching part can guarantee some level of performance even if Spring by nature have to start a new session/connection/producer to each transmission, so the same connection/session get cached to reuse and avoid overhead by extending SingleConnectionFactory.
DelegatingConnectionFactory is for mature application server so that the CF/transaction management is in the hand of the server(Websphere MQ, JBoss HornetQ etc) so that this CF plays as a delegation and leaves the workload to the server. So the actual performance depends on how to tune up app server's CF and queue and transaction management.
I may be too drunk to make this up so please correct me if above does not make sense. I have one more question base on this comparison that, if Spring JmsTemplate by nature have to open/close session and all to each transmission, then how we can improve the performance by utilize the JmsTemplate with the app server's jms management?
I'm having trouble finding a simple example of a JTA transaction spanning multiple resources (e.g. two databases, a database and a JMS queue, etc.)
I've spent a lot of time reading up on this and have working samples of doing a JTA transaction with a JMS queue, and a JTA transaction over a JDBC database driver. I just can't seem to find anything on making both the JMS queue and the JDBC database part of the same JTA transaction.
Can anyone provide a brief sample or a link to something that does demonstrate how to use the JTA API for this purpose?
For a JTA transaction to coordinate amongst JMS and JDBC resources, the following is required:
XAConnectionFactory - a JMS XA-compliant connection factory must be available in JNDI; the specific one to use depends on your application server/container.
XA-compliant JDBC driver - the driver must be XA, most databases provide one, and the connection must support READ_COMMITTED isolation level, anything less won't be sufficient.
Aside from that, if you're using an app server, the container will handle transactions automatically if you're using message driven beans and XA-compliant drivers.
Check these links for exmaples:
http://blog.inflinx.com/2010/04/08/spring-jta-jpa-jms/
http://www.oracle.com/technetwork/java/faq-140431.html#relship_transac