This chapter is from the book
This chapter is from the book
This chapter is from the book
Conclusion
In this chapter, we have examined the basics of HTTP session management and outlined some options for maintaining application state with HTTP session. We've seen how WAS implements HTTP session and covered the two approaches for persisting session data to a database and memory to memory. We also covered some of the performance implications of the session management configuration options and discussed some troubleshooting approaches.
1 It's worth noting that this is actually a poor use of a session. Sessions are not designed for robust "permanent" storage. By storing the shopping cart in a session, if there were a client failure (perhaps the browser crashed), the user would lose his or her entire shopping cart. That's a great way to lose a sale. Important information is better stored in a database directly.
2 This is because all the application servers (in both cells) must be defined as "clients" to that server, and the admin console only gives you the ability to provide one replicator IP address and port at a time on a server, so if that replicator were to go down, then it would amount to a SPOF (single point of failure). This differs from the default behavior in a single cell, where the multiple application servers in a replication domain can be configured in a "client server" configuration.
3 The longer default interval was simply the result of limited testing and development resources that were available prior to the V5.0 release. The 10-second interval is a recommended starting point in V5.0 and V5.01, though you may want to tune it for your application and environment.