• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Cookies and session timeout

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How do you reconcile these two specs:
HTTP Spec: Lifetime of Cookie
* In its default state, a cookie erases when your browser closes.
* If you want a cookie to last longer, you must set a time stamp for the expires attribute.
Serv Spec: Session Timeouts
* By definition, if the timeout period for a session is set to -1, the session will never expire.

It seems "never expire" means a really long time, because cookies require a time stamp. I wonder how it's done. Do the containers decide what "forever" means (eg, 30 years)?

PS: I was confused about the name, JSessionID and found out Spec says BOTH cookie name and URL suffix/parameter MUSTbe named JSessionID
[ March 01, 2005: Message edited by: P. Dunn ]
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A cookie lifetime lasts as long as a session lasts, which not always means when you close the browser. There are some settings that let you to work on the same session from different windows (I know, it's bad but that's it).

If you set the session-timeout to -1 it means that a session will never expire as long as the container will be up and running. However, if the series of circumstances for which a session is ended (note: not expired) occurs (in the normality of cases when a browser window closes), the session will also be invalidated. The expiration time is calculated by the following:



Now, the code is not EXACTLY like this, but it gives you an idea. If you want a Cookie to last more, you can use the Cookie.setMaxAge() method, which accepts an int (representing seconds)
[ March 01, 2005: Message edited by: Marco Tedone ]
 
P. Dunn
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I see your point about normal curcumstances. Normally you'd shutdown the container at least a few times a year, I'd assume, making most of this issue theoretical.

However, this is the thing that is odd to me. If cookies must have an expiration date, a session timeout of -1 just means the session will last only as long as the cookie's expiration, which is determined arbitrarily by the container. So, effectivly, there's no "ever-lasting" session

BTW, in your code, correct me if I'm wrong, but I believe you meant
[ March 02, 2005: Message edited by: P. Dunn ]
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As regards cookies, their lifecycle doesn't control the session lifecycle, probably it's the opposite. As I said, even if the session timeout has got a value of -1, most of the time when the user closes the browser the session will be killed, and the cookie too.

As regards my code, I meant exactly what I wrote but obviously there are different checks to invalidate a session. I think it's possible to check how long a session has been alive by using the following code:

sessionLive = System.currentTimeMillis() - HttpSession.getCreationTime()

This is probably the mechanism used for the session-timeout element.

Your code would return a value which represents the interval between when you run your code and when the session was last accessed. If you meant to know the interval between the current request and the previous one, then your code is correct, provided that a setMaximumInactiveInterval() method was previously called. This way you could check if your result is > than getMaximumInactiveInterval() then HttpSession.invalidate, and this would be the second way of invalidating the session.
[ March 02, 2005: Message edited by: Marco Tedone ]
 
P. Dunn
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the cookie were gone, there would be no way to reassociate the user with the session. So it would never used again. An HttpSession that could never be reassociated with a user would be garbage, and for all practical purposes, invalidated. (Though it would still exist as an object.)

The cookie is not eliminated when the browser closes. It's reused until the cookie expiration date passes.

Though VERY ambiguous in the Servlet spec, I believe the session-timeout element is different from what you call "sessionLive." I believe the container periodically looks for expired HttpSessions. I would define InactivePeriod as measured from the LastAccessedTime to now, irrespective of creation time. The primary concern is reclaiming inactive session objects. I understand your interpretation, though.

Someone needs to rewrite the DTD where it defines:
"The session-timeout element defines the ... session timeout..." Doh!

PS To Add one other odd detail:
According to the DTD:
* If the timeout is 0 or less, session will not expire.
According to the API:
* setMaxInactiveInterval(int interval)if interval<0, session will not expire.(if interval==0, session expires immediately. Wow! Somebody fix that!)
For cookies:
* A negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits. A zero value causes the cookie to be deleted. (Though different it makes sense, because cookies must have some timestamp.)
 
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To add one more point of clarification...

the cookie name is JSESSIONID and the url parameter name is jsessionid

They are case sensitive.

My interpretatiom of Session Timeout is inactive time (Now - LastAccessTime)

-C
 
P. Dunn
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks! good catch.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic