Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Integration Server Administrator's Guide | Configuring Integration Server for webMethods Messaging | Load Balancing with a Non-Clustered Group of Integration Servers | Important Considerations for Using a Stateless Cluster with webMethods Messaging
 
Important Considerations for Using a Stateless Cluster with webMethods Messaging
Keep the following points in mind when determining whether to connect a non-clustered group of Integration Servers to the same messaging provider for load-balancing:
*The Integration Servers in the group must be the same version and at the same fix level.
*The Integration Servers in the group can share a document history database and a cross-reference database.
*The actions that Integration Server takes when modifying triggers in a non-clustered group Integration Servers depends on the value of the Client Prefix Is Shared option:
*If the Client Prefix Is Shared option for the Integration Server connection to the messaging provider is set to Yes, Integration Server prevents updates to shared objects on the messaging provider.
In a non-clustered group of Integration Servers for which the Client Prefix Is Shared option is Yes, it is your responsibility to manually update the settings on the messaging provider.
*If the Client Prefix Is Shared option for the Integration Server connection to the messaging provider is set to No, Integration Server allows updates to shared objects, such as a queue or channel, on the messaging provider. Modifying a webMethods messaging trigger on one of the Integration Servers could delete documents and other data on the messaging provider. For example, when the messaging provider is Broker, if you enable a trigger, disable a trigger, or change the processing mode, the Integration Server deletes and then recreates the associated trigger client queue on the Broker. This action deletes any documents that are in the trigger client queue on the Broker.