What are the considerations when configuring two Inprise Application Servers?

From Support
Jump to: navigation, search
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:

  • The Naming service
  • The Session Storage server

You have the following objects which are not stateful:

  • Inprise Application Server (IAS)
  • The EJB container
  • Your stateful session EJBs

==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:

  1. Running a single naming service, via the command line:
  2. Running a single EJB container with only the Session Storage service, via the command line:
  3. Run two IAS instances without a naming service:
  4. Disable the naming service via the console.
  5. Run two containers (from these IAS instances) each without a Session Storage service.

To disable the Session Storage service:

  1. Select the properties for the EJB containers
  2. Disable the jss property.
  3. Restart the EJB containers.

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