Mediator processes routing rules in parallel based on the following principles:

• Mediator queues and evaluates routings in parallel in different threads.

  The messages of each Mediator service component are retrieved in a weighted, round-robin fashion to ensure that all Mediator service components receive parallel processing cycles. This is true even if one or more Mediator service components produce a higher number of messages compared to other components. The weight used is the message priority set when designing a Mediator service component. Higher numbers of parallel processing cycles are allocated to the components that have higher message priority.

  You can set the Priority field in the Mediator Editor to indicate the priority of a Mediator service component. Priorities can range from zero to nine, with nine being the highest priority. The default priority is four.

  Note:

  The Priority property is applicable only to parallel routing rules.

• Mediator initiates a new transaction for processing each parallel rule. The initiated transaction ends with an enqueue to the Mediator parallel message dehydration store.

  For example, if a Mediator service component has one parallel routing rule, one message is enqueued on the Mediator parallel message dehydration store. The parallel message dispatcher to the store then initiates a transaction, reads the message from the database store, and invokes the target component or service of this routing rule. The transaction initiated by the listener thread is a completely new transaction and is propagated to the target components.

  Note:

  Dehydrating of messages means storing the incoming messages in a database for parallel routing rules so they can be processed later by worker threads.

• Mediator commits or rolls back transactions because it is the initiator of these transactions.