23.07.2013 Views

O'Reilly - Java Message Service

O'Reilly - Java Message Service

O'Reilly - Java Message Service

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Java</strong> <strong>Message</strong> <strong>Service</strong><br />

avoids processing the first message if the second message fails to be delivered. If the<br />

messages were to be separately acknowledged, the client could fail after the first message<br />

was acknowledged, but before the second message was fully processed. If this occurred,<br />

the first message would be considered delivered by the JMS provider, yet not fully<br />

processed by the client. It would be effectively lost. Delaying acknowledgment provides a<br />

way to write the application so that it behaves correctly when failures occur. If you still<br />

have your B2B application up and running, try typing the request for surfboards in the<br />

command window for the QWholesaler application:<br />

Surfboards, 999.99, 499.99<br />

Notice that some output appears in the QRetailer window to indicate that the message was<br />

received. Kill the QRetailer application by hitting Ctrl-C in its command window. Next,<br />

type in the second line item in the QWholesaler application:<br />

Wetsuits, 299.99, 149.99<br />

Now restart the QRetailer application. You should see output in the QRetailer window<br />

indicating that both the Surfboard message and the Wetsuits message have been received.<br />

This new instance of the QRetailer receives both messages because the earlier instance of<br />

QRetailer never sent an acknowledgment for the first message. Therefore, when we<br />

restarted the QRetailer, the JMS provider redelivered the Surfboard message, and then<br />

sent the Wetsuits message. A single acknowledgment is now sent, acknowledging both<br />

messages. The JMS provider has now fullfilled its part of the contract with the receiving<br />

application, and can remove the messages from its persistent store.<br />

6.3.2.1 Compensating transactions<br />

In the code that deals with the redelivered flag, we introduced a call to<br />

processCompensatingTransaction( ):<br />

private void autoBuy (javax.jms.<strong>Message</strong> message){<br />

int count = 1000;<br />

try {<br />

...<br />

if ( saveDesc == null )<br />

{<br />

if ( message.getJMSRedelivered( ) )<br />

processCompensatingTransaction( );<br />

processInterim<strong>Message</strong>s( itemDesc );<br />

return;<br />

}<br />

...<br />

}<br />

}<br />

This code is executed when the client restarts and receives redelivered messages, as was<br />

the case in the client failure exercise we just went through. The first message of the<br />

sequence will have the redelivered flag set on the message, causing the<br />

processCompensatingTransactions( ) method to be invoked:<br />

private void processCompensatingTransaction( )<br />

{<br />

saveDesc = null; // null out "saved" work<br />

}<br />

94

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!