I had an interesting discussion with Martin Grotzke (the guy creator of the memcached-manager for Tomcat) and during that discussion he raised some good points when configuring standalone instances of tomcat/resin.
In the case of non-sticky sessions, a session is never loaded from the memory of the app server. The session will always have to be loaded from store (in our case a database) for each request. Since the sessions are non-sticky, requests can go to any Resin/Tomcat instance. Concurrent requests can go out from the client’s browser (multiple windows or tabbed-browsing).In such a case some kind of “session locking” needs to be done since multiple requests may access/modify the same session object. There is no clear documentation in Resin if they have implemented any session locking but Tomcat does not have any such session locking when configured as a standalone instance. Period!! .
In the case of sticky-sessions, a request will always go to the same Resin/Tomcat instance ( which the session was first created on).But we still need to handle concurrent requests accessing the same session object. One way this would be achieved is by ensuring we do all the session value modification (setAttributes) in a synchronized block. But we all know it would affect performance when handling multiple concurrent requests.
Till next time…..