Running Multiple Instances of the TIBCO iProcess® Objects Server

You can run multiple instances of the TIBCO iProcess® Objects Server. This is done in the following ways:

Note 

To be able to run multiple instances of TIBCO iProcess® Objects Server, your server must have CR 10974 implemented.
• On Multiple Machines in a Node Cluster

If you’ve saturated the resources of a single machine, you can add TIBCO iProcess® Objects Servers to other machines in the cluster, allowing you to spread the load across multiple machines. All nodes in the cluster share the same database.

To run the TIBCO iProcess® Objects Server on multiple machines, it must be installed on each of the machines in the cluster on which it will be running. As an example, if the TIBCO iProcess® Objects Server is installed on two machines in the cluster, the process_config table will appear as follows:

 

Machine ID

Process Name

Process Instance

1

SPO

1

2

SPO

1

This shows that there is a single instance of the TIBCO iProcess® Objects Server installed on each of the two machines.

• On a Single Machine

Multiple instances of the TIBCO iProcess® Objects Server can be run on a single machine, resulting in all TIBCO iProcess® Objects Servers running from the same $SWDIR directory and using the same database. This allows you to run multiple TIBCO iProcess® Objects Servers without requiring you to have a cluster. The reasons for running multiple instances of TIBCO iProcess® Objects Server on the same machine are:

— It increases throughput by reducing SAL threading contention. Each instance has its copy of the SAL, so by spreading the same number of users over several instances (and SALs), contention can be reduced. (Threads in one process do not contend against threads in another process trying to enter the same critical section.)
— It avoids the process-size limitation that is imposed in some operating systems. Since a large component of the size of a TIBCO iProcess® Objects Server is user-related data, a TIBCO iProcess® Objects Server with fewer users will be smaller. Therefore, spreading a given user load over multiple servers yields smaller servers.