The flow of business information from adapters to the server, as well, as
from the server to adapters, is a vital component of the WebSphere InterChange
Server functionality. With the marked increase in the use of JMS
Transport, enhancements were necessary to ensure the highest quality in
performance, throughputs and scalability.
InterChange Server stores events in a persistent storage for recovery
purposes. In a non-optimized state, this storage could be very costly,
especially if the business object is expansive. In an optimized state,
the event is left in the message queue and referenced in the database.
When all event subscribers have completed their work, the message is deleted
from the queue.
By synchronizing information in the critical sections, events can be
retrieved sequentially from the queue, ensuring a retainable event sequence as
well as a scalable server in a multi-processor environment.
In order to achieve JMS Transport optimization, the InterChange Server
provides the following enhancements:
- Improve caching - queue objects are cached within the sender,
enhancing adapter performance
- Batch database operations - business object events are
accumulated in an ordered list and then persisted together in a batch
operation, reducing the performance issues raised by frequent database
operations
- Optimize JMS recovery - increase the event persistence
performance, speed recovery operations and adapter response
This section covers the following topics:
"Optimization versus non-optimization"
"Steps for activating and de-activating optimization"
Although message transport is now optimized, there is also a need for
transport to run in a non-optimized state , dependant upon business
need. Switching from optimized to non-optimized allows users to swap
messaging providers, if necessary, to accomodate the needs of their
vendors.
You may opt to use a non-optimized state when business object events are
small in size, or when database overhead is insignificant. However,
prior to switching between an optimized and a non-optimized state you must
wait until all queued events are recovered. Events running in an
optimized state cannot be redelivered to InterChange Server in a non-optimized
state.
- Note:
- Optimization is designed to have minimal impact on in-bound service calls and
Long Lived Business Process (LLBP) events, which will both continue to process
as non-optimized events. This is possible since the optimized state can
process both optimized and non-optimized events.
Perform the following steps to activate and de-activate JMS transport
optimization:
- During the connector configuration, select the check box for JMS
Optimization.
- Set the value of the following connector properties. Once set, the
connector configuration will upgrade the configuration files.
- jms.TransportOptimized - True delivers
events through optimized WIP.
- jms.ListenerConcurrency - specifies the number of
concurrent listeners for JMS transport. This property appears
whenjms.TransportOptimized is set to True.
- Note:
- If JMS is set as the transport, the default value for the
jms.TransportOptimized property is False.
When jms.TransportOptimized is set to True, the
JMS provider (jms.FactoryClassName) must be IBM MQ.
- To switch back to the non-optimized state, first ensure that the server is
not currently processing any events and the delivery queue is clean. If
you attempt to switch from an optimized state to a non-optimized state there
are remaining events in the delivery queue, an error will display when the
connector deploys to InterChange Server.
- Clear the check box for JMS Optimization.
- Set the value of the following connector properties. Once set, the
connector configuration will upgrade the configuration files.
- jms.TransportOptimized - False delivers
events through non-optimized WIP.
