I am new to JMS. I am trying to understand what is difference between JCA JMS (Java Connector Architecture) and Plain JMS. I tried finding it through the web, but I didn't find anything satisfactory. Can we write a code using JCA JMS which is supported for both WebLogic and JBoss?
From an API perspective there is no difference between "JCA JMS" and "Plain JMS". The difference is in how they behave. A JCA-based JMS connection factory has 2 big advantages over a plain JMS connection factory:
Pooled - Generally speaking, when a connection is "created" from a JCA-based JMS connection factory the underlying physical connection is taken out of a pool and when the connection is "closed" the underlying physical connection is returned to the pool. This eliminates the performance penalty of actually creating and destroying the physical connection which allows clients to be written in ways that would normally be considered an anti-pattern (e.g. "creating" and "closing" a connection for every sent message).
Automatic enlistment into JTA transactions - Most of the time applications running in a Java EE application server which consume JMS messages do so via an MDB. By default, the consumption of the message in an MDB (i.e. the execution of onMessage) happen within a JTA transaction. If a JCA-based JMS connection factory is used in the course of the MDB's processing (e.g. to send a message) then the JCA logic will automatically enlist the session into the JTA transaction so that the consumption of the message and the sending of the message are an atomic operation (assuming that the JCA-based connection factory is XA capable).
I would expect that you could write application code that would behave the same in both WebLogic and JBoss AS.
Related
I'm trying to use Spring JMS messaging with #JmsListener in a scalable way, but I'm not seeing it happening. I have a ConnectionFactory bean that returns a factory that connects to an Oracle Advanced Queue through JMS and a database DataSource pool.
The problem starts as every #JmsListener receiver connects again to JMS (and hence to the database pool). My understand is that I can have many #JmsListener methods, one for each service, but in this way it's doing I'm very limited.
The shared connection is turned on, but since each #JmsListener creates a different DefaultMessageListenerContainer, each one have a database connection.
If I also want the services to handle messages concurrently and set container.setConcurrency("3-5"), then it opens 3 * numberOfListeners connections.
If I use container.setCacheLevel(DefaultMessageListenerContainer.CACHE_NONE) then from each second every listener container connects and disconnects from the JMS/database.
I want something that connects one time (or more, if there is concurrent jobs to process) to JMS/database, not to connect count-of-listener times nor to connect-disconnect at each second for every listener.
You can use a SingleConnectionFactory to wrap the vendor factory and all containers will use the same connection.
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.
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
All,
i am new to JMS and i have a question about Session.rollBack() method in JMS. AFAIK, this method is used to roll back all operations to JMS server (sending/receiving) by the session when using *SESSION_TRANSACTED* acknowledge mode. Now suppose I am calling this method in a catch block of a receiving/processing operation (is reasonable?), to tell JMS server to redeliver the message for processing, But even if it is redelivered the processing still throws the same exception which cause the JMS server to redeliver the message again, so it seems a infinite process. How to handle this problem? or are there any other JMS features that is designed for it? Thanks in advance!
The rollback method in JMS will rollback any message sends and receives in that "transaction". Transaction here is local to the JMS session.
Whether a redelivery will cause a problem really depends on why the exception occurred. If it was due to some transitory issue then a redelivery may work. If you have the kind of problem that is once it occurs will always occur (an example of this would be a JMS TextMessage whose body should contain XML, but doesn't).
The JMS API doesn't provide any solution to this itself. This is typically taken care of by the JMS provider and how it behaves will depend on which one you use. WebSphere MQ for instance will redeliver up to a configurable maximum at which point it will move it off to a queue for bad messages. The Service Integration Bus in WebSphere Application Server has similar behaviour. I suggest you consult your JMS provider documentation to determine exactly how it behaves in this situation.
If you are running in an application server rollback typically doesn't do anything because the application server will be managing transactions for you.
To process a large number of messages coming to a queue i need guarantee of at least one jms connection to be there at any time. I am using spring and spring allows to have multiple sessions on a single connection only. In case one and only connection fails, application will come to standstill till spring reconnects to the JMS bridge.
So how can i create more than one connection to a queue in Spring, also how can i do connection pooling here.
The answer to this depends on whether you are using Spring inside a J2EE container(jboss etc.) or in a standalone application.
Standalone - you'll find pooling connections to be a problem. Springs SingleConnectionFactory can be setup to renew the connection on an exception garaunteeing that at some point a connection will come online and start processing the queue again, but you'll still have the problem of waiting for that single connection to renew, plus depending on what messaging implementation your dealing with and how it does load balancing you may find yourself stuck with a connection to a single node in a cluster.
If you are running in a container you can rely on the containers connection factory which will be much more robust. JBoss Messaging in the container for instance will failover seamlessly to other nodes and handles pooling under the covers, but if your working in the container its usually easier to bail on JMS template which kind of sucks and use whatever that container provides.