Hi all,

    I am really asking very basic question that what is HTTP Session?

 Yes, you will get a lot information on googling.

But i wanted to know that where the session object is maintained,

so that the server identifies the unique client?

Is it transfered to and fro with request and response?

As each request is processed at server in a separate thread,

and each time we access the session object through request. [i.e. request.getSession()].

So does the server maintains the sessions of all the requests some where or each time it

gets from incoming request.

And what if we put large objects in the session variable?


Please make these concepts clear.

Thanks & Regards,

Sandip Bhoi

When a page request is processed by the ASP.NET runtime (the aspnet worker process) the session information for the particular requester (i.e. the client instance based on the asp session cookie or querystring value) is provided to the page class that is instantiated for each aspx page. Internally the HTTPSession class associates the data to the client based on the session ID.

The data itself is maintained by the web server. If using in process session (InProc) the session data is kept in server memory and thus can be lost if the web application restarts. If using SQL server based session, the data is persisted in a SQL database which makes it easy to use session in a web server farm. Because of the physical persistence provided by a SQL database session data is kept as long as the session ID is valid regardless of environment changes such as application restarts. No session information is passed between he client and server apart from the session ID token itself. Look in your cookies and you'll see the session ID.

You can put large objects into session. The only real limitation is server memory. It's a good practice to clean up the session variables you no longer need. Unlike the garbage collection of the framework runtime, because session is designed to provide some form of "persistence" to a stateless application platform, it hangs around until it's erased, the web app is restarted or the session the data belongs to times out. Depending on how you design your application you could be in trouble if you need to put lots of large objects into session. That might also flag a problem with the application design.

-Peter

Thank you Peter,

     Thank you very much for explaining this in details.

Again some query --

Is there any thing on browser related to Session?

The browser is having the cookie JSESSIONID which contains the unique session id. The cookies travels to and fro with request and response.

Then does the server identify the same session of the client from session id in the cookie?

Can cookie modified at client side? what if the cookie is modified at client side? It may interfere with other session and every thing may go wrong...

Please explain this thing.

Thank you once again for spending you precious time for the same.

-Sandip Bhoi

Yes, the session ID cookie, but that's all. No session data resides in the browser.

Don't you mean "SESSIONID" (no J)? Yes the server identifies "who" the user is based on the session id in the cookie. That's how it matches up the in memory data to a user.


Yes, technically you could change your cookie. If you change the session ID in the cookie, you'll most definately affect the way the application behaves. If you were able to spoof another user's session ID you could then operate in their session. This is why user authentication should be maintained in something like a forms authentication ticket which is encrypted and much more difficult to hack.

-Peter