The ActiveMQ project site, 2004–2007 · independent archive
Independent historical archive. This site preserves the ActiveMQ project pages that were published at activemq.org in 2004–2007. It is not the project’s website and is not affiliated with or endorsed by the Apache Software Foundation. ActiveMQ and Apache are trademarks of the ASF. For current downloads and documentation go to activemq.apache.org.

Archive › Documentation › Should I use transactions

Archived page

Should I use transactions

Archived from http://www.activemq.org/site/should-i-use-transactions.html, captured 2006-06-29 · view the capture · Added by James Strachan, last edited by James Strachan on May 09, 2005

You often have to choose between how you consume messages. The choices are

  1. auto-acknowledgement
  2. explicit acknowledgement via Message.acknowledge()
  3. JMS transactions
  4. XA

For a discussion on XA try Should I use XA

The main difference between 1 & 2 and 3 & 4 is the latter allow things to be rolled back and redelivered if there is a failure while processing. There is no JMS 'unacknowledge'. So for this reason JMS transactions should be preferred to message acknowledgements in most use cases.

Incidentally, its a common misconception that transactions are slow; there's no real difference between a JMS transaction and a Message.acknowledge() from an architectural perspective in ActiveMQ; the only real issue is whether you are using persistent messaging and so must block until the commit is synchronized to disk (much the same way you must block with a Message.acknowledge() in a non-transactional JMS session). Note that transactions are available in non-persistent modes too - which are very lightweight and mostly client-side facades only.

Its also worth noting that if you are using persistent messaging, the fastest way of using JMS is to actually use transactions and use batching; so you can send 1000 messages, all of which are asynchronous and super fast, then do one commit ever batch to minimise the latency involved with waiting for things to be synced to disk. (The same is tru e for consuming or mixed consume and produces etc).

More from the archive