0

I have read about both session object and cookie. Session objects are maintained on server side. Cookies are stuff which are maintained clients side and sent to server per request by browser. Some doubts I have that I am still not able to clarify are

1.)In ASP .NET sessions can be tracked through cookies. Using stuff like below in the configuration file

<configuration>
  <sessionstate 
      mode="inproc"
      cookieless="false" 
      timeout="20" 
      sqlconnectionstring="data source=127.0.0.1;user id=<user id>;password=<password>"
      server="127.0.0.1" 
      port="42424" 
  />
</configuration>

What is the equivalent Java servlet configuration for above and where is it configured?

2.)In Java in case cookiefull state tracking is enabled then do we still have to write code to pull out the cookie from the request and using it get session object details, or is this done internally by the J2EE framework, i.e. the J2EE framework sees the cookie and automatically assigns the respective session object to the page request?

seahorse
  • 2,420
  • 4
  • 31
  • 40

2 Answers2

2

ASP.NET and J2EE are different in the sense that J2EE is just a specification for enterprise java applications, and it lacks the actual implementation. There are a lot of implementation for J2EE, here's a list: http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers.

If you look at the HttpServletRequest interface you'll notice the getSession() method, which returns the HttpSession in there it says:

The server can maintain a session in many ways such as using cookies or rewriting URLs

The different servers can handle this in different ways. You'll need to find your answer for a specific server, i.e.: Supporting Sessions Without Cookies in Tomcat.

Community
  • 1
  • 1
Nitzan Tomer
  • 155,636
  • 47
  • 315
  • 299
1

Java EE Containers default session management is using cookies (although it supports other methods, like URL rewriting).

There's no need -and you shouldn't- manage session cookies on your own because the container does all this stuff for you. It exposes an instance of HttpSession that represents the session of the current user: if you want particular objects to persist between requests you can store here as attributes and recover later accessing that HttpSession object. There no need to write cookie-related code.

Carlos Gavidia-Calderon
  • 7,145
  • 9
  • 34
  • 59