If message order must be maintained in all circumstances, a destination
can be configured so that the order of messages is preserved much more rigorously
than for a normal destination.
In general, messages produced by a single producer to a single destination
are seen by a consumer to that destination in the same order as they are produced.
However, there are certain topologies and events, such as system failures,
that can change the order of messages (see Message ordering for details). If strict message order is essential
then you can configure a destination to preserve the order of the messages
in a much more rigorous manner. Using strict message ordering, in conjunction
with restricted topologies (as described below), maintains message order in
all circumstances.
Restrictions that are enforced automatically
When
you include a strictly ordered destination in your system, certain restrictions
are automatically enforced at run time. These restrictions affect the way
that applications can interact with the destination to ensure strict message
order, so you must ensure that you fully understand each of the following
restrictions before configuring a destination to be totally ordered.
- Concurrent consumers are prevented from attaching to an ordered destination. Having
more than one consumer consuming from a destination can result in messages
being consumed out of order. So, for an ordered queue destination, and any
subscription on an ordered topic space, one consumer at most can attach at
any one time. This is equivalent to setting "receive exclusive" to true on
a queue destination and "Share durable subscriptions" to "never shared" on
a JMS topic connection factory, and warnings are generated in the system log
to indicate if these options have been overridden. The attached consumer is
also restricted to a single transaction at any one time (this is the normal
behavior for many messaging interfaces so should not affect many users, for
example, JMS).
- Partially consumed messages prevent subsequent messages from being
consumed. For standard destinations (that is, destinations without the
strict message ordering option enabled), messages that have been partially
consumed from the destination (for example, received within a transaction
that is yet to be committed) might be skipped over by a consumer to allow
processing of messages to continue past previously consumed messages that
are yet to be committed. This can disrupt message order. For an ordered destination,
such messages are not skipped by a consumer, instead the consumer is blocked
until the message has either been totally removed (for example, the uncommitted
transaction is committed) or replaced (for example, the uncommitted transaction
is rolled back). This situation would occur if a previously attached consumer
fails to commit a transaction that was used to consume messages from the destination,
or if a transactional resource becomes temporarily unavailable during the
commit of a transaction. If the resource is permanently unavailable, see Resolving indoubt transactions for information
on resolving these transactions.
- Concurrent message driven beans (MDBs) are restricted for an ordered
destination. The maximum concurrent endpoints and maximum batch size settings
of any MDB deployed on an ordered destination are overridden to be one (see JMS activation specification [Settings]).
This ensures the ordered processing of messages by the MDB. When the system
overrides this property at run time, a warning is generated in the system
log.
- Concurrent mediations are restricted for an ordered destination. The
allow concurrent mediation setting of any mediation on an ordered destination
is overridden to be false (see Concurrent mediations). This ensures the ordered processing of messages by
the mediation. When the system overrides this property at run time, a warning
is generated in the system log.
- If Automatically stop endpoints on repeated message failure is
enabled then the Sequential failed message threshold is
overridden to 1.
Additional restrictions that might affect message ordering
Even
with strict message order enabled on a destination the following restrictions
are not automatically enforced, but they could affect message ordering and
therefore should be understood: