AFAIK HttpSession chooses by itself which method of tracking to use - if the client allows cookies, it will use them. If not, it will manage the session server side. Cookies is the most effective way of tracking - but it depends on what extent you want to track - the session, the request, the application lifetime etc. HttpSession is ideal for session tracking - Cookies are better for Application tracking such as a user disconnecting from a dial up, and connecting a few days later - if the user has not flushed his cookie bin, then you can still recognise him.
A couple of points I'd like to clarify: Firstly, cookies aren't files sent by the server, they are sent as text in the HTTP header and then saved as a file on the filesystem if required - they don't always get saved. The cookies used for HttpSessions are usually session cookies, and for security reasons they don't usually get written to the file system (ie only memory-resident), but this is browser specific behaviour. If the browser is closed, memory-resident session cookies are lost and you no longer know who the user is. Unless you specifically write some user data to a persistent cookie, and then only if the client accepts it, there is no way to track users from one day to the next. For eample, javaranch writes the userId as a cookie which gets saved to the filesystem. This is why you don't have to login each day. Dave
Joined: Apr 24, 2002
so basically it is my choice as to what to use, right??? since it is not always possible for a persistant cookie i have the option to use HTTPSession... i'm just folowing some projects from deitel&deitel and they gave examples doing both: 1. Cookie cookies = new Cookie(name, value) response.addCookie(cookies) 2. HttpSession session = request.getSession(true) session.putValue(name,value) cookies get added to the response thus to the client HTML but session doesn't... am i getting it write??? [ November 27, 2002: Message edited by: Benjoe Reyes ]