Never Virtualize

This policy enforces that messages between components (or between a binding and a component) are always routed via in-memory transport, and not via the virtualization queues that use the Enterprise Message Server (EMS). If the target component is not available and hence the message cannot be routed in-memory, the invocation fails with an exception. When used in conjunction with a transaction policy, this will cause the transaction to be rolled back.

This policy supports a specific use-case where a SOAP/JMS or JMS binding with a 'JMS Transacted OneWay' policy wired to several components and managed by a single transaction. In this use-case, a transaction starts at the SOAP/JMS binding and spans several components, and it is expected that if the transaction rolls back, the incoming messages are returned to the external JMS queue.

As an example, suppose we have a component C1 wired to C2. When C2 is stopped, it will result in an exception, causing the invocation from C1 to C2 to fail. Without the 'Never Virtualize' policy, the message would have been routed to an internal virtualization queue for future delivery when C2 is back up and running.

The 'Never Virtualize' policy has the opposite behavior of the 'Virtualize' policy. As such, both these policies can be used with or without a transaction policy, and both control the internal message routing.

Comparison between these policies as applied to the example of C1 wired to C2:

• Never Virtualize policy
  • Forces the use of in-memory transport.
  • C1 and C2 must be co-located in the same node for this policy to be useful.
  • Causes C1's invocation to fail when C2 is down/absent on the same node.
• Virtualize policy
  • Forces the use of EMS-based transport using an internal virtualization queue.
  • Invocations work when C1 and C2 are on the same or different nodes.
  • Causes C1's invocation to be blocked when C2 is down/unavailable. The message is delivered later when C2 comes back up.
  • Cannot be used for the above use-case since virtualized queues are always used.

• Default (neither of the two policies declared):
  • Automatically chooses whether to use in-memory routing or EMS-based routing depending on whether C2 is running or not on the same node as C1.
  • Cannot be used for the above use-case since virtualized queues will be used when C2 is unavailable

When the 'Never Virtualize' policy is used together with a transaction policy, ensure that the transaction policy be configured with a finite number of attempts for message delivery. For example, while using 'JMS Transacted OneWay' policy, the 'Max redelivery count' parameter must have a finite non-zero value. Using the default value of zero implies infinite re-delivery attempts and will cause the system redelivering messages to itself continuously and infinitely when one of the components is stopped or the transaction rolls back due to any other reason.