HTTP Session failover and performance

One of my colleagues wrote a good article that covers HTTP session failover.  There are performance implications to using HTTP sessions and persisting them.  This spurs me to start a series of articles to discuss some of the pros/cons with these mechanisms. 

Before session persistence existed there was no fail over capability for sessions.  This is, though, probably the most performant deployment.  Sure, users have to log back in but the application server doesn't have to spend time on serializing objects and then pushing them out to a database.  You save on both memory (for the serialized objects) which then have to be garbage collected which is paid for through CPU utilization. 

If your business requirements can stand it, and require users to relogin in a failure, then this is a good deployment strategy.  I know a number of intra departmental applications that can tolerate such activity. 

The WebSphere Contrarian: Back to basics: Session failover

My preferred alternative is to rely not on session distribution, but instead to rely simply on HTTP server plug-in affinity to “pin” a user to an application server, although this does mean that stopping an application server JVM will result in the loss of the HttpSession object. The benefit of doing so is that there is no need to distribute the session objects to provide for HttpSession object failover when an application server fails or is stopped. The obvious down side is that a user will lose any application state and will need to log back in and recreate it, and this may or may not be acceptable for your application or business requirements. I'll mention that I’ve worked with a number of customers that in fact agree with this view and make this their standard practice.