svn commit: r1005610 - in /websites/production/activemq/content: cache/main.pageCache should-i-use-transactions.html

[bu...@apache.org]

Author: buildbot
Date: Wed Jan 25 21:22:59 2017
New Revision: 1005610

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/should-i-use-transactions.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/should-i-use-transactions.html
==============================================================================
--- websites/production/activemq/content/should-i-use-transactions.html (original)
+++ websites/production/activemq/content/should-i-use-transactions.html Wed Jan 25 21:22:59 2017
@@ -72,19 +72,7 @@
   <tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent">
-<p>You often have to choose between how you consume messages. The choices are</p>
-
-<ol><li>auto-acknowledgement</li><li>explicit acknowledgement via Message.acknowledge()</li><li>JMS transactions</li><li>XA</li></ol>
-
-
-<p>For a discussion on XA try <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 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.</p>
-
-<p>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.</p>
-
-<p>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).</p></div>
+<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 deliv
 ery 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 t
 he 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>
         </td>
         <td valign="top">
           <div class="navigation">