Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 Messages : Sending Messages Synchronously and Asynchronously

Sending Messages Synchronously and Asynchronously
TIBCO Enterprise Message Service supports two modes of sending messages:
Synchronous sending blocks the application thread until the entire send is complete.
Asynchronous sending offloads the notification of the success or failure to another thread, thereby increasing performance in certain situations.
Each sending mode has certain benefits. The following sections describe the benefits of the different modes.
Sending Synchronously
Because synchronous sending does not have the overhead involved in asynchronous sending, it yields better performance in most cases. Synchronous sending is also the best choice when sending the following types of messages:
Non-Persistent Messages  When high performance is a concern, use synchronous sending for non-persistent or reliable messages. Although asynchronous sending of non-persistent messages is supported, it is generally not recommended.
Transactions  Typically, it makes sense for applications to use synchronous sending when using transactions. Sending messages within a transaction does not require a response from the server, so higher throughput can be obtained sending synchronously within a transaction.
Synchronous sending simplifies a transaction; coordination of asynchronous send notifications and committing or rolling back a transaction introduces complexity to the application.
See Sending Messages for details.
Sending Asynchronously
The message producer can send messages asynchronously by registering a completion listener to monitor message send success or failure. Operating in a thread separate from that of the message producer, the completion listener manages the response to a successful or failed send, leaving the message producer free to perform other operations. See Creating a Completion Listener for Asynchronous Sending for details.
Asynchronous sending can increase performance in certain circumstances. One of the best uses for asynchronous sending is when sending persistent messages. High level outgoing message throughput can be obtained when sending non-transacted persistent messages.
There are other considerations for the application programmer when sending messages asynchronously. These considerations are described below.
Concurrent Message Use
For simplicity, it is suggested that application programmers create a new message for every asynchronous send call. If concurrent message use is acceptable in an application, messages may be reused when sending asynchronously, but generally it is not recommended due to the complexity it may add.
For example, if a TextMessage is asynchronously sent with the text of foo, and then the same message object's text is subsequently set to bar, it is conceivable that when the completion listener is invoked the message will contain bar even though it contained foo at the time it was sent.
Memory Use
Application programmers should be aware that some additional memory is used by the EMS server when asynchronously sending. Memory use increases if the performance of completion listeners is slower than overall application send rates.
Fault Tolerant Failovers
Because send notifications are handled in a separate thread when messages are sent asynchronously, it is possible to receive messages out of order after a fault tolerant switch.
For example, consider an application that sends messages A, B, and C. Message A succeeds, Message B fails, but message C succeeds immediately after reconnect to the fault tolerant server. The application may not know message B failed before message C was sent. Message consumers could conceivably receive messages in the order of A, C, B; it is up to the application to appropriately handle this situation.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved