A small change in what said before: the application is currently in production with JBoss 4.0.2 and not 3.x.
In the general case ordered redelivery is very hard to guarantee.
Consider a queue with several transactional sessions and consumers consuming from it.
The consumers are consuming at different rates, and every so often they rollback (or fail). When they rollback, their unacknowledged messages go back on the queue.
The order they go back on the queue is determined by the order in which they rollback (or fail). So you can see its not deterministic.
For the special case of having only one session and consumer on a particular queue, then, yes, JBoss Messaging will try to redeliver the messages in the same order as they were first delivered, but we don't provide any hard guarantees of this over and above the JMS spec.
If you are using MDBs the situation is further complicated, since the app server can obtain several messages from the underlying JMS provider in one go before forwarding to the MDB.
Probably the only reason you are seeing ordered redelivery with MDBs is that JBM does local delivery on rollback (i.e. does not force a NACK like JBoss MQ). I wouldn't guarantee this behaviour stays for ever.
So the bottom line is, no we don't guarantee ordered redelivery, although you may see something that looks like ordered redelivery under some circumstances.
I'm a collegue of Egomet (my name is Mirco) and I'm working on the same task of Egomet.
In the next weeks I will study how to patch JBoss/HornetQ to obtain the ordered redelivery using a special configuration to avoid multithreading problems.
If you are interested to our solution I will send the patch (using the right procedure) for the commit.
We found a solution using JBoss 4.0.2 but now we want to upgrade the AS so I would like to insert it in the head line of the sources.
Thanks for your time.
If you're talking about HornetQ, you're in the wrong forum.