Conclusion

Storing session state in a persistent database or using memory-to-memory replication provides a degree of fault tolerance to the system. If an application server crashes or stops, any session state that it might have been working on would normally still be available either in the back-end database or in another still-running application server's memory, so that other application servers can take over and continue processing subsequent client requests associated with that session.

You can find more information about this topic, including traces and logs, in 6.3, Web container clustering and failover (Web server plugin), and Chapter 6 of WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392

Secure authentication cookie

This is used to manage authentication data. An authentication cookie flows over SSL and is timestamped for maximum security. This is the cookie used to authenticate the user whenever a sensitive command is executed, for example, the DoPaymentCmd, which asks for a user's credit card number. There is minimal risk that this cookie could be stolen and used by an unauthorized user. Authentication code cookies are always generated by WebSphere Commerce whenever cookie-based session management is in use.

Both the session and authentication code cookies are required to view secure pages.

For cookie errors, the CookieErrorView is called under the following circumstances:

• The user has logged in from another location with the same logon ID.

• The cookie became corrupted or was tampered with, or both.

• If cookie acceptance is set to true and the user's browser does not support cookies.

xxxx