Many thanks for your quick response, ksak.
2008/11/12 <glassfish_at_javadesktop.org>:
> ...
> From an MDB perspective, the spec states that message ordering is not guaranteed by the container.
Ah, I hadn't checked the spec before, here's the relevant passage:
5.4.11 Concurrency of Message Processing
A container allows many instances of a message-driven bean class to be
executing concurrently, thus
allowing for the concurrent processing of a stream of messages. No
guarantees are made as to the exact
order in which messages are delivered to the instances of the
message-driven bean class, although the
container should attempt to deliver messages in order when it does not
impair the concurrency of message
processing.
Message-driven beans should therefore be prepared to handle messages
that are out of
sequence: for example, the message to cancel a reservation may be
delivered before the message to
make the reservation.
...
> Other than the redelivery issue you've seen, there are two other problems with approximating
> serialized delivery by setting the number of endpoints to 1. The first is reduced performance.
> One of the benefits of MDBs is the ability to concurrently process messages. Second, if your
> application assumes a single thread of serialized delivery it can't be deployed to a cluster.
OK, thanks. I see it's best I don't try to force the MDB mechanism to
be something it isn't.
I guess I'll write the ordered message details into a table, and just
use the JMS message as an
asynchronous "ping" to go lookup the next one to process.
As each "ping" will be identical in content, the order won't matter so
long as the ping count is correct.