This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
In the deployment descriptor, I have set <session-timeout>0<session-timeout> for a servlet, so that session never expires. Now, in a scenario where many users are connected and none of the users 'logout', will it create too much burden to the container?
Rajesh(Bangalore,India)<br />SCJP2, SCWCD, SCEA, IBM-XML, UML-OOAD, IBM-Enterprise Connectivity with J2EE.
There are 2 ways to kill a session: 1) HttpSession.invalidate; 2) or session timeout has expired. Another mock exam question states that even the container is shutdown and brought up again, the session still persists. -yu chen
Joined: Aug 15, 2002
Yeah, yu Chen, the two ways you mentioned are perfect. But, my question is, if there are thousands/millions of active sessions(and unused) and we are not killing the session will it create unwanted burden on the container? Thanks.
Sessions surely do impose a burden on the container.
If your servlet uses sessions, or if your JSP does not specify session="false", every visitor gets a session eating up a bit of memory. Memory requirements become directly proportional to load.
Distributed containers share sessions between JVMs, meaning that session data is serialized over the network (often by storing it in a database, e.g. WebSphere). The overhead involved is proportional to both the number of sessions and the size of your session data; store more than 2-4KB of session data and performance under load sinks through the floor.
A quick example: if your JVM has 1GB of memory allocated to it, half of this is available for session data with a 4KB footprint per session, sessions take half an hour to time out, and an average user spends 10 minutes on your site, you are memory-limited to 524,288/4 * 10/(10+30) = 32,768 simultaneous users per server. This is fine; CPU and I/O constraints are likely to limit you to 1,000 - 10,000 users per server anyway. On the other hand, if you have only 128MB available for session data, you happily store 100KB worth of garbage in the session (don't laugh, I've seen this and worse), and users spend an average of 3 minutes on your site, you are memory-limited to 131,072/100 * 3/(3+30) = 119 users. You will run out of memory long before you run out of CPU or I/O bandwidth. I should really add that these example assume that the container does not passivate sessions. If it does, in the last example, the container can passivate the session shortly after the user has left the site (3 mins) without impacting performance too much, improving scalability tenfold to about 1000 users. Memory would still represent a significant bottleneck though. When building massively scalable sites or applications, avoid sessions as much as you can, time them out as quickly as you can, and aggressively invalidate them wherever you can. - Peter [ September 05, 2002: Message edited by: Peter den Haan ]
Joined: Aug 15, 2002
Thanks Peter, it was very informative.
Peter den Haan
Joined: Apr 20, 2000
Upon rereading, I haven't directly addressed the question: yes, never timing out sessions is just about the worst possible thing you can do; unless you invalidate sessions in another way, session data will only grow. Good containers will passivate them, but a passivated session often still has a small memory footprint. Ultimately you will run out of memory or disk space. Even if you have some other mechanism of invalidating sessions, it is very hard to guarantee that a session will be invalidated. Browsers may crash, networks may go down and your magic code may never be called. So I would always want to set a (very long) timeout to give me that guarantee. - Peter [ September 05, 2002: Message edited by: Peter den Haan ]