简体   繁体   中英

JMS Local transactions vs TransactionManager

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?

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM