All,
This has to be a question that arises again and again. I did search a bit but did not find anything pertaining to my situation.
We are designing a session-based application which will use affinity maintaining load-balancing infrastructure. The users are call-center agents - so the typical usage
pattern is to initiate a session, spend 4-5 minutes, kill the browser and initiate another session. Every time we have an entity that is session scope (not useful across sessions), we have the choice of placing it in the session object or in a cookie. Which approach is ideal?
LOGIC TO PLACE IN SESSION
It is a session scope entity, and should, as such reside in the session object. Since the LB infrasstructure gaurantees session affinity, we should leverage it and save on the network overhead that placing it in the cookie would incur. Cookies have length limits and (potentially) security issues that we can avert by using the container provided Session object. Cookies are more appropriate for information that spans sessions.
LOGIC TO PLACE IN COOKIE
Placing more and more data in the Session object make it larger and places a higher load on the server resources. Reducing the session size by placing entities in the Cookie allows the same application to serve more users. This is all the more so true in an application where users come and go at a high rate, while they spend 4-5 minutes in each visit. If the application throws an error for a particular request, the LB infrastructure will redirect the user to another instance. The new instance will have session information from the cookie and can continue seemlessly.
Thoughts/ideas???
[ May 25, 2005: Message edited by: Sharad Agarwal ]
[ May 25, 2005: Message edited by: Sharad Agarwal ]
[ May 25, 2005: Message edited by: Sharad Agarwal ]