JMS Local transactions vs TransactionManager

Question

I have been looking into the Jms API lately and I am not certain I understand the local vs transaction manager differences.

Scenario 1:

Consume message from Jms broker, process the message and commit transaction once processing succeeds otherwise rollback.

Scenario 2:

I want to proxy messages from one broker to another broker but I do not want to use XA transactions due to its slow nature. So the idea is to start a transaction for the broker I am consuming from and then within that transaction start a second transaction for the broker I am producing to and then commit the two transactions in succession. Lets ignore the issue of the duplication risk in this scenario which can be mitigated

What exactly is the difference to between using JMS commit(), rollback() APIs (Aka Local Transactions) vs using a Transaction Manager such as Spring's PlatformTransactionManager class? Is a transaction manager necessary in the second scenario at all and why so/not?

As you stated that XA transactions are slow due its nature may I be curious where have you taken your statement from? — chalda
From my own experience comparing Non-XA vs XA transactions. From reading up on how much more work an XA transaction has to do to keep N resources synced I figure that is the cause of the difference in performance — Alexandre Thenorio
Thanks for reaction. My interest came from your second scenario as I have impression that you want to simulate XA transactions without XA. Would that mean that you don't want to use resource locking? — chalda
I mean you don't mind if message is lost in a case? Like a problem when you read a message, commit txn receiving message and your application crashes. Then such message was forgotten during the process. Or am I wrong here? XA transaction does have its overhead but on other hand it is capable to recover system after crash. — chalda
No losses occur however duplication can. You read from broker 1 on txn 1 and send to broker 2 on txn 2 then commit txn 2 followed of a commit on txn 1. If application crashes between the 2 commits you get the same message on both sides cause potential duplication. — Alexandre Thenorio

Scott Sosna Scott Sosna · Accepted Answer · 2016-02-07T23:23:33

Transaction managers are going to ensure that the transaction spanning servers is either going to be committed together or rolled-back together.

Manually managing separate transactions opens up holes, such as Server A transaction committed but Server B can't be because of any number of error conditions (network, application failure, etc.). There are many scenarios like this where a transaction manager mitigates the issues.

It might be that your application is idempotent and can handle seeing the same messages multiple times and handle it correctly or that there are process flows issues that can correct for bad situations, in which case you're probably fine.

JMS Local transactions vs TransactionManager

1 Answers