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 runtime. 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) may 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 runtime, 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 runtime, a warning is generated
in the system log.
Additional restrictions that may 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: