Does each application server have a vendor specific limit on how many HttpSessions it can handle at a given moment ? Any idea what's the limit for Tomcat ? thanks.
I do not believe that Tomcat, or other servlet containers, impose any artificial limits on the number of active session other than that dictated by the limitations of resources (such as available memory).
the number of sessions would not be a fixed number, but depend on the resources available.
For example: if in an application, the session needs to store only one StringBuffer object then we may be able to store many sessions, but if the session were to store many more 'big' objects, in that case, memory would be required to store those objects, thus reducing the total number of objects to be stored...
William Brogden
Author and all-around good cowpoke
Rancher
Joined: Mar 22, 2000
Posts: 12271
1
posted
0
Servlet containers are allowed to Serialize sessions to disk or other storage so they do NOT have to keep all active sessions in memory. Thats why you should ensure that all objects "stored" in sessionss should implement Serializable. Bill
Frank Sikuluzu
Ranch Hand
Joined: Dec 16, 2003
Posts: 116
posted
0
Originally posted by William Brogden: Servlet containers are allowed to Serialize sessions to disk or other storage so they do NOT have to keep all active sessions in memory. Thats why you should ensure that all objects "stored" in sessionss should implement Serializable. Bill
How about HttpRequest ? will there be any chance that requests are serialized to disk ? I guess not, but not sure. Please confirm if you know the answer.
By the way, sessions are first stored in memory so it consumes memory. Where are "requests" stored ? Do they also eat memory ?
How about HttpRequest ? will there be any chance that requests are serialized to disk ? I guess not, but not sure. Please confirm if you know the answer.
By the way, sessions are first stored in memory so it consumes memory. Where are "requests" stored ? Do they also eat memory ?
Requests do not get serialized to disk. They only last a fraction of a second (except in fringe cases).
Because of the transient nature of requests containers often pool and recycle request objects to cut down on object creation.