On 23/04/2015 14:24, Sreyan Chakravarty wrote: > I beg to differ but every time a new request is sent to the server, Tomcat > creates a new session for it.
Not correct. > So yes Tomcat creates a session even if the application does not ask for it. Also not correct. > Every unique session generates an unique session id on the server. Yes, every session has a unique ID. Mark > > On Wed, Jan 21, 2015 at 1:06 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 21/01/2015 06:04, sreya...@gmail.com wrote: >>> Is there any way for stopping sessions to be created for each >>> “first-time” GET request to an ordinary page ? >> >> Don't create a session in that page. Tomcat doesn't create a session >> unless the application asks for it. >> >> Note: >> - JSP pages create sessions by default but this behaviour is configurable. >> - FORM auth requires a session in order to work >> >> Mark >> >> >>> Because doesn't it >>> seem redundant that even if the developer is not using the session, >>> the server will still create one ? >>> >>> >>> A real life popular website has millions of users at a time. So how >>> come the server is not overloaded by sessions ? >>> >>> >>> >>> >>> >>> >>> Regards Sreyan Chakravarty >>> >>> >>> >>> >>> >>> From: Christopher Schultz Sent: Sunday, January 18, 2015 >>> 12:28 AM To: Tomcat Users List >>> >>> >>> >>> >>> >>> Sreyan, >>> >>> On 1/17/15 12:45 PM, sreya...@gmail.com wrote: >>>> I am new to Tomcat and interested in learning how to works >>>> internally. I was reading the following thread on JavaRanch but it >>>> did not give a concrete answer-: >>> >>>> http://www.coderanch.com/t/467039/Tomcat/sessions-stored >>> >>> Tim Holloway answered this in the second response on "10/19/2009 >>> 5:48:56 AM". >>> >>>> Does the container use an Array-List or a HashMap to store the >>>> HTTPSessions? >>> >>> The servlet specification does not mandate any particular storage >>> mechanism, so the container is free to decide what is best. >>> >>>> What is the limit of the maximum sessions? >>> >>> There is a very large theoretical maximum of (Integer.MAX_VALUE/2) * >>> Integer.MAX_VALUE because String values (session ids) are limited to >>> MAX_VALUE characters and characters are identified by integers. But >>> you'll run out of storage (or any kind) way before that. >>> >>>> Are the sessions stored in RAM? >>> >>> The servlet specification does not mandate any particular storage >>> mechanism, so the container is free to decide what is best. >>> >>> In Tomcat, sessions are stored in memory (Java heap) by default. >>> There are other mechanisms that can persist session information to >>> various places. The standard manager will persist sessions to the >>> disk during webapp reloads, but otherwise the sessions reside >>> exclusively in memory. >>> >>>> I am aware that persistent sessions will need a data-store/database >>>> to the sessions. But how does it handle the non persistent ones ? >>> >>> I encourage you to look at the source for StandardManager if you >>> want to really know what's going on. >>> >>>> I have also consulted-: >>>> http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html >>> >>>> But this too failed to give the location of non-persistent >>>> sessions. >>> >>> Java heap memory. >>> >>>> Anyone who does Tomcat development and meddles around with the >>>> source, there feedback will be highly appreciated. >>> >>> Check the source code. Start with >>> org.apache.catalina.session.StandardManager >>> >>> -chris >>> >>> --------------------------------------------------------------------- >>> >>> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
