One subject that keeps cropping up with customers is the subject of message order. Now I’ll say up front, having a requirement to maintain the order of messages in an application is a bad thing. If messages can’t be processed in parallel due to ordering constraints then the resulting application is unlikely to scale and high availability will be difficult to achieve. This, however, doesn’t seem to stop people wanting it, so here’s a few things you should know about message order and the service integration bus.
Firstly, and most importantly, RTFM. The InfoCenter has a good introduction to what is required to maintain message ordering. Most of those requirements are under the control of the application architect and administrator. One issue that still existed in WebSphere Application Server Version 6.0 was in the area of transaction recovery. If a message should end up in-doubt due to server failure (the messaging engine has received a prepare from the transaction manager but no commit or rollback), then the messaging engine must wait for the transaction manager to perform recovery and indicate the direction of transaction completion. In Version 6.0, the messaging engine would continue to deliver other messages from the destination in the meantime, thereby losing message order.
In Version 6.1 of the Application Server, a new property “Maintain strict message order” has been added to a destination. This restricts the concurrency of consumers, mediations and MDBs, and, all importantly, ensures that messages are not delivered from a destination whilst others on that destination are still in-doubt. You need to consider the consequences of this though. If the messaging engine to which the destination is assigned is highly available then, even though the messaging engine may start on another server, messages may be blocked until the recovery logs for the original server are processed. Consequently, you may also wish to consider enabling failover of the recovery logs to another server.
As discussed in the InfoCenter, this new property does not, on its own, guarantee message order. One particular restriction that is worth discussing further is that, if the destination is assigned to a cluster bus member, then there should only be a single messaging engine associated with that bus member. With multiple messaging engines, a queue will have multiple queue points, with messages being workload managed across them. For some applications it may be sufficient that messages on the same server are processed in order, even if there may be other, later messages being processed ahead of them on another server. There is still an issue here though as, if a message is sent to a queue point that turns out to be full, it will be redirected to a queue point on another messaging engine, possibly arriving out of order.
Even if the intricacies of this discussion are lost on you, I hope that it is sufficient to persuade you that message ordering is indeed a bad thing!