Hi,
I found a solution.
I create a session which never expires (expiry set to infinite) and invalidate it
manually: then I have full control which requests
mean a new access.
I do it by setting up a new cookie with value='session creation time' when creating
the session.
Then at each access (all requests except polling requests) I set the new access time
into the existing cookie.
Axel Lannion/France
> -----Original Message-----
> From: Gokul Singh [SMTP:[EMAIL PROTECTED]]
> Sent: mercredi 7 mars 2001 13:49
> To: [EMAIL PROTECTED]
> Subject: Re: sessionId used by applet to poll other servlet within
>same JV M: d isturbs sessions MaxInactiveInterval
>
> ----- Original Message -----
> From: "Bartsch Axel" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
>
> [snip]
> > I tested it: the applet really sends the sessionId-cookie.
> >
> > What I still don't understand:
> > The polled servlet never calls anything of the session: it does not call
> request.getSession() whatsoever.
> > So why is this polling "click" taken into account and stops the session
> from expiring? Does the sessionAPI come into action automatically?
> > If yes at which stage of request processing?
>
> Section 7.6 of the specs ver 2.3 PFD say
>
> <from-specs>
> 7.6 Last Accessed Times
> " The getLastAccessedTime method of the HttpSession interface allows a
> servlet
> to determine the last time the session was accessed before the current
> request. The session is
> considered to be accessed when a request that is part of the session is
> handled by the servlet
> context."
> </from-specs>
>
> This to my reading means that when ever the container gets a request which
> belongs to a session, that session is assumed to be accessed. You do not
> need to explicitly do the getSession().
>
>
> > What do you think of following solution:
> > servlet side: somehow delete the cookie with the sessionId in the request
> in routine doPost(),doGet()? Or is this already too late?
> > applet side: somehow prevent the cookie from being sent in the request?
>
> Both approaches can work if there is a way to achieve it. I do not know of
> anyway to do this, but it might be possible.
>
> Regds,
> Gokul
>
>
>
> > > -----Original Message-----
> > > From: Gokul Singh [SMTP:[EMAIL PROTECTED]]
> > > Sent: mercredi 7 mars 2001 06:12
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: sessionId used by applet to poll other servlet within
> same JVM: d isturbs sessions MaxInactiveInterval
> > >
> > > ----- Original Message -----
> > > From: "Bartsch Axel" <[EMAIL PROTECTED]>
> > >
> > > > The strange thing now is the session never ends? It seems that this
> > > polling keeps the session running: the polling is interpreted as user
> > > action.
> > >
> > > The polling *is* a user action. Only in your case the HTTP requests are
> > > being generated by the applets which is no different from a user
> initiated
> > > request from the Servlet Containers view point.
> > >
> > >
> > > > Now why does this happen and want could be done to prevent it?
> > >
> > > The cookies are being passed back to the container to the container
> which
> > > then recognizes this request to be part of a session. So the session
> does
> > > not get timed out. To prevent the same you can turn off the cookies for
> > > session management (if your container supports it) and use URL rewriting
> for
> > > session management. Another way to do this would be the path to which
> the
> > > session cookies are returned, but again it is a very container specific
> > > thing.(iPlanet 6.0 app server supports it, Tomcat does not, iPlanet 4.1
> web
> > > server does not......)
> > > I am not sure how can one do it with cookies being used for session
> > > management other than to establish raw socket connection for the polling>
> or
> > > wrapping ones own session mgmt aroung the servlet's session API .
> > >
> > >
> > > > Is the sessionId cookie set within the applet??
> > >
> > > I think you are using the URLConnection to do the polling. When you use
> this
> > > class, then it uses the browser API(in applets) to make the connection
> and
> > > this results in session cookies being sent to server. I am not sure, but
> may
> > > be this behaviour can be overriden in the plugin control.
> > >
> > >
> > > > Why does servlet2 within the same JVM interpret this session? It was
> > > created for servlet1. (sometimes sessions should be shared between two
> > > servlets: but not here).
> > > > And even if servlet1 woyld be polled this should not happen!
> > >
> > > Session are *not* per servlet concept. They are a *per client* concept
> to
> > > maintain state across multiple requests from the same client as the HTTP
> > > protocol itself is stateless. If you are not getting what I am saying
> here,
> > > you may want to do some reading [1,2] on session management.
> > >
> > >
> > > Regds,
> > > Gokul
> > >
> > > [1]
> http://java.sun.com/docs/books/tutorial/servlets/client-state/index.html
> > > [2] I would recommend Jason Hunter's Java Servlet Programming chapter 7.
> > >
> > >
> > > >
> > > > Axel Lannion/France
> > > >
> > >
> > >
> ___________________________________________________________________________>
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources: http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
> ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
