The multisend guaranteed policy specifies that the JMS client should send the same JMS message to exactly n out of m Brokers in the Broker cluster. The publishing operation is successful only if the JMS message is sent to precisely n Brokers. The policy specifies that if the JMS client cannot send the JMS message to the precise number of Brokers successfully, the JMS client should not send the JMS message to any Brokers.

To ensure that Integration Server sends the JMS message to the exact number of Brokers, Integration Server uses an XA transaction to perform a two-phase commit. Integration Server manages the entire transaction as part of executing the pub.jms:* sending service. Consequently, regardless of the connection type of the JMS connection alias, the multisend guaranteed policy does not require special configuration or set up in the sending service or the JMS connection alias.

When sending a multisend guaranteed JMS message using a connection with a transaction type of NO_TRANSACTION, Integration Server starts the transaction when it begins executing the pub.jms* service. Integration Server dynamically adds the n participating Brokers to the transaction. (Integration Server treats each Broker enlisted in the transaction as an XA resource.) After n Brokers receive the message, Integration Server commits the transaction and the pub.jms* service completes execution.

However, if you want more control over the transaction or if you want to enlist other resources in the transaction, use a JMS connection alias with a transaction type set to XA_TRANSACTION or LOCAL_TRANSACTION. Integration Server can then use an implicit or explicit transaction to send the message.

When sending a multisend guaranteed JMS message in an implicit transaction, Integration Server starts the transaction when executing the pub.jms* service that specifies a JMS connection alias of type XA_TRANSACTION or LOCAL_TRANSACTION. Integration Server commits or rolls back the transaction when the top-level service executes to completion. When the transaction type is XA_TRANSACTION, Integration Server logs the state of each transaction. This XA transaction logging allows Integration Server to recover any transactions that did not complete due to Integration Server failure.

When sending a multisend guaranteed JMS message in an explicit transaction, you control the transactional units of work by defining the start and completion boundaries of the transaction. The parent service that sends the JMS message must use the pub.art.transaction* services to start, commit, and roll back the transaction. Integration Server enlists the Brokers as XA resources when it executes the pub.jms:* service.

In some situations, you might use the built-in service pub.art.transaction:startTransaction to start a transaction explicitly, but then allow Integration Server to commit or roll back the transaction implicitly based on the success or failure of the top-level service.

By default, Integration Server performs transaction logging only when the JMS connection alias has a transaction type of XA_TRANSACTION. However, you can configure Integration Server to perform transaction logging whenever it sends a JMS message as part of a multisend guaranteed policy. For more information about transaction logging, see Transaction Logging with the Multisend Guaranteed Policy.

For more information about sending a JMS message within a transaction, see Sending a JMS Message as Part of a Transaction.