Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What is a Session?  RSS feed

 
Aaron John
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am new to web programming so can anyone here define (in simple term) what a Session is? Also what is a request and does it have any relationship with a session? Hope someone can help me.
 
Marcelo Ortega
Ranch Hand
Posts: 528
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I recommend reading up on this, but basically, a Session (actually a HttpSession object when talking in servlets) is basically a way for the client to identify himself each time he makes a request (because http is a stateless protocol and never holds a persistant conection between the client and the server). The identification is done with a unique value represented by the jsessionid cookie or parameter (depending on whether cookies are enabled or not and if url re-writting is used.

To explain this properly i'd be he for hours, there is so much to write on this topic. Do a google search to find out more.

Best regards,
Mars.
 
bimal upadhyay
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
A session is something like time when a perticular client login. When client login the session is to be maintain from login till the client is logout.Most online trading site use the session concept.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Session adds a stateful component to a stateless protocol.

HTTP is stateless, meaning the server forgets everything about the client as soon as it sends a response. HTTP provides no way to build up a shopping cart on the server for example.

Session holds state from the time it is created - I think you always get one even if you never use it - until it is destroyed - programmatically or by timeout. So if you want to build up a shopping cart you can put each item selected into a collection on the session, then put shipping information and credit card information on there too.

Session eats up memory. If you have more than a few concurrent users you should keep the amount of data on there as small as possible. Session resides in memory only (by default) so if a user can bounce from one server to another in a cluster you'll have to persist it to a database or find another state solution.

Any of that help?
[ January 20, 2006: Message edited by: Stan James ]
 
Aaron John
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
Session adds a stateful component to a stateless protocol.

HTTP is stateless, meaning the server forgets everything about the client as soon as it sends a response. HTTP provides no way to build up a shopping cart on the server for example.

Session holds state from the time it is created - I think you always get one even if you never use it - until it is destroyed - programmatically or by timeout. So if you want to build up a shopping cart you can put each item selected into a collection on the session, then put shipping information and credit card information on there too.

Session eats up memory. If you have more than a few concurrent users you should keep the amount of data on there as small as possible. Session resides in memory only (by default) so if a user can bounce from one server to another in a cluster you'll have to persist it to a database or find another state solution.

Any of that help?

[ January 20, 2006: Message edited by: Stan James ]


Yes that is very helpful. I have another question. I see that HTTPSession and HTTPServletRequest objects have setAttribute() method. What is the difference between setting attribute in session and setting attribute in request?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66205
151
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The request object exists only for the duration of a single request-response cycle. The session, as pointed out, has a longer lifetime.

So scoped variables (the term for objects tacked onto a scope using setAttribute) should be placed on the scope that is approriate for the lifetime of the variable. If it's only needed during the current request cycle, it should be placed in request scope. If it needs to exist beyond the durrent request, and is specific to the current user, it should be placed on the session. If it's an application-wide variable that all users should have access to, it should be placed in application scope.

In a JSP page, a 4th scope, page scope, is also available.
[ January 20, 2006: Message edited by: Bear Bibeault ]
 
Kamesh Loganathan
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Pal,
One important thing about session is that the session object is maintained on the server. And the session ID is held by the client browser as a cookie or in the URL. This way the browser maps to the particular session on the server.

So if the client losses the sessionId or the server discards the session object, the user has to login again

As of scopes are concerned , there are 3 or 4.not sure.
1. Application scope - This is like a static variable.It can be accessed throughtout the application by all the users.
2.Session scope-this can be accessed only with in the session
3.Page scope- this can be accessed throught the JSP page.
4.Request scope- this can be accessed only in that request
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!