Recently, I’ve been working with applications that require very few postbacks. While this has been great from a usability perspective, after all the application is very ajaxy and responsive, it’s caused some unexpected problems. One problem that it caused is that ASP.NET Sessions were expiring even though the user was actively using the application.
The Sessions were expiring because the user wasn’t causing a postback (full or partial) and thus executing the ASP.NET page life cycle, which takes care of maintaining Session for us by implementing the IRequireSessionState interface.
One way I could have solved this problem is to rehydrate Session whenever an Ajax request was received (such as by marking the web method as requiring Session), but this is a bad programming practice for a few reasons. First, having Session attached to a request and response isn’t very RESTful and breaks at least a couple of design rules. Second, it’s a relatively expensive operation to pull Session from the session store, deserialize it into the Session object, use it, maybe modify it, and then serialize it back out to the Session store when the request is complete. As Session gets bigger, this operation gets more expensive and I really want the Ajax features of the application to fly. Finally, I might not own the REST endpoints that I’m using for my application’s functionality. In that case, I’m talking to a third party service (i.e. Amazon’s S3 service), and not communicating at all with my application, but I still need to keep Session alive. The user doesn’t know or care that I’m talking to Amazon. They just think they’re using my application.
What I really wanted to do was sometimes revalidate Session while the user interacted with the Ajaxy parts of the application without the user paying any perceivable performance penalty and not breaking too many rules of application design.