blob: 262c030cd07ebe6ab8ec4e5152361e379519a580 [file] [log] [blame]
<div class="wiki-content maincontent"><p>There are four main approaches as to a client can consume messages. They are:</p><ol><li>Auto-acknowledgement</li><li>Explicit acknowledgement via&#160;<strong><code>Message.acknowledge()</code></strong></li><li>JMS Transactions</li><li>XA</li></ol><p>For a discussion on XA see: <a shape="rect" href="should-i-use-xa.html">Should I use XA</a></p><p>The main difference between 1 &amp; 2 and 3 &amp; 4 is the latter allow messages to be rolled back and redelivered if an error occurs whilst processing. There is no JMS 'unacknowledge'. So for this reason JMS transactions should be preferred to message acknowledgements in most use cases.</p><p>It's a common misconception that transactions are inherently slow. In reality there's little difference in performance, from the broker's perspective, between the use of a JMS transaction and invoking <strong><code>Message.acknowledge()</code></strong>. However, a performance penalty is incurred when the delivery mode is set to&#160; persistent. This causes the broker to block until the commit is synchronized to disk. This is similar to how <strong><code>Message.acknowledge()</code></strong> blocks when using a non-transactional JMS session.</p><div class="confluence-information-macro confluence-information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body">Transaction support is also available for non-persistent delivery mode.</div></div><div class="confluence-information-macro confluence-information-macro-information"><p class="title">Batched Transactions Are The Fastest Way To Process Messages!</p><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">It's worth noting that the fastest way to consume persistent messages is to use a JMS transaction combined with message batching, e.g., have the commit boundary encompass multiple messages, not just one.&#160;This applies to both producers and consumers and to clients that are both.</div></div><p>When using transactions a batch of 1000 messages, say, can be sent in a single atomic step. The message transmission is asynchronous and therefore very fast. The producer need only perform one commit every batch in order to minimize the latency that would otherwise be incurred with disk syncing.</p></div>