Managing Transactions in Clusters
During transactional processing in a webMethods client-side clustering environment for JMS, all the messages published in a transaction are routed to a single Broker in the cluster determined by the cluster policy. In a transactional publish operation, the cluster policy applies to a transaction instead of a message. Whereas in a non-transactional publish operation, each message is distributed to a different Broker based on the cluster policy.
For example, consider that you have configured an XA cluster connection factory with a round robin load balancing policy. The following steps lists the sequence of transaction processing operations in a webMethods clustering environment for JMS client applications.
1. webMethods API for JMS starts the transactions on each of the Brokers in the cluster using the same transaction xid in all the Brokers.
2. Publisher application publishes the messages to the cluster. According to the round robin policy, all the messages of the first transaction are routed to Broker 1. Broker 1 to which all the messages of the transactions are published becomes the participating Broker of this transaction. The messages of the next transaction are routed to the next available Broker in the cluster.
Subscriber application connects to all the Brokers in the cluster to receive the transaction messages. The transaction messages are gathered from the individual message threads on each cluster Broker and retrieved on a first-come-first-serve basis. Note that if the subscriber receives the messages from Broker 1 and Broker 2, Broker 1 and Broker 2 will become the participating Brokers at the subscriber end. If any of the participating Brokers at the subscriber end goes offline, the commit operation for that transaction will be affected. If any of the non-participating Brokers goes offline, the transaction is not affected.
Once all the transaction messages are received, the Broker client ends the transaction.
3. webMethods API for JMS prepares the actively participating Brokers in the cluster.
The prepare operation returns a value indicating the result of the transaction or returns an appropriate XAException for rolling back the transaction.
4. webMethods API for JMS commits the transaction on the participating Brokers. The transactions started in the remaining non-participating Brokers will be rolled back automatically.
The commit operation does not report the errors occurred during a rollback of non-participating Brokers as an XAException.
5. In case of a rollback, webMethods API for JMS rolls back the transactions on each of the participating Brokers.
The transactions started in the remaining non-participating Brokers will also be rolled back. The rollback operation does not report the errors occurred during rollback of non-participating Brokers as an XAException.
6. The recover operation obtains the list of transaction branches that are currently in the prepared or heuristically completed state on each of the Brokers in the cluster. The transaction manager executes the recover operation during recovery to obtain the list of transaction branches that are currently in prepared or heuristically completed state.
The recover operation throws an appropriate XAException if an error occurs on any of the participating Brokers in the cluster during recovery.
7. The forget operation forgets all the heuristically completed transaction branches on each of the Brokers in the cluster.
