----- 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
