|
|
Unless you have only a single appserver or your application is completely stateless, maintaining state between HTTP client requests also plays a factor in determining your configuration. Use of the session information, however, is a fine line between convenience for the developer and performance and scalability of the system. It is not practical to eliminate session data altogether, but care should be taken to minimize the amount of session data passed. Persistence mechanisms decrease the capacity of the overall system, or incur additional costs to increase the capacity or even the number of servers. Therefore, when designing your WebSphere environment, take session needs into account as early as possible.
In WebSphere V6, there are two methods for sharing of sessions between multiple appserver processes (cluster members). One method is to persist the session to a database. An alternate approach is to use memory-to-memory session replication functionality, which was added to WebSphere V5 and is implemented using WebSphere internal messaging. The memory-to-memory replication (sometimes also referred to as "in-memory replication") eliminates a single point of failure found in the session database (if the database itself has not been made highly available using clustering software).
You can find details in 2.4, Managing session state among servers.
