Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Both of the methods proposed in the question appear to rely on a single instance of the app. What's wrong with using multiple app instances, transacted sessions and COMMIT? The performance reports (these are the <a href="http://ibm.co/SupptPacs" rel="nofollow">SupportPacs</a> with names like MP**) all show that throughput is maximized with multiple app instances, and horizontal scaling is one of the most used approaches in your scenario.</p> <p>The design for this would be either multiple application instances or multiple threads within the same application. The key to making it work correctly is to keep in mind that transactions are scoped to a connection handle. The implication is that a multi-threaded app must dispatch a separate thread for each connection instance and the messages are read in the same thread.</p> <p>The process flow is that, using a transacted session, the app performs a normal <code>MQGet</code> against the queue, processes the message contents as required and then issues an <code>MQCommit</code>. (I'll use the MQ native API names in my examples because this isn't language dependent.) If this is an XA transaction the app would call <code>MQBegin</code> to start the transaction but for single-phase commit the transaction is assumed. In both cases, <code>MQCommit</code> ends the transaction which removes the messages from the queue. While messages are under syncpoint, no other app instance can retrieve them; MQ just delivers the next available message. If a transaction is rolled back, the next <code>MQGet</code> from any thread retrieves it, assuming FIFO delivery.</p> <p>There are some samples in:<br> <code>[WMQ install home]\tools\dotnet\samples\cs\xms\simple\wmq\</code><br> ...and <code>SimpleXAConsumer.cs</code> is one example that shows the XA version of this. The non-XA version is simpler since you don't need the external coordinator, the <code>MQBegin</code> verbs and so forth. If you start with one of these, make sure that they do not specify exclusive use of the queue and you can fire up several instances using the same configuration. Alternatively, take the portion of the sample that includes creation of the connection, message handling, connection close and destroy, and wrap all that in a thread spawner class.</p> <p>[<em>Insert usual advice about using the latest version of the classes here.</em>]</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload