What are the considerations when configuring two Inprise Application Servers?
What are the considerations when configuring two Inprise Application Servers for failover? |
In any distributed system, there are objects which are stateful and objects which are stateless. For the particular scenario you are running you have the following stateful objects:
You have the following objects which are not stateful:
==Note:==You might not automatically think that your EJBs are stateless, but since their state is stored in the Session Storage server, they are in fact stateless. The simplest configuration is to have only a single instance of each of the stateful objects, and to make sure the stateless objects use those single instances. In IAS, this means:
To disable the Session Storage service:
Alternatively, you can run the Naming and the Session Storage service via a third instance of IAS, but this probably requires a third box. If you want to have fault-tolerance of the Naming service itself, this can be done by configuring two Naming service instances: one as the master and one as the slave. Please refer to the Naming service documentation for details. Currently, the Session Storage service does not have a replication capability. However, it is simply an IDL object with three methods; therefore, replacing it with a fault tolerant version (backed against a database) would not be hard. Note:Neither replicating the naming service nor replicating the Session Storage service actually eliminates the single point of failure. You have just moved the single point of failure to the database layer.
|
Article originally contributed by Borland Developer Support