Apologies. A misunderstanding.
I have only one tomcat server. The "different machines" in question
are different client machines.
Interestingly tomcat doesn't appear to be trying to put anything in
the cookie!!! I have another page which uses javascript to manipulate
the cookie and (when I switch on your suggested option) IE prompts to
ask whether I should allow it to store that cookie. In no other
circumstance does IE prompt to ask about storing a cookie.
So... How is tomcat keeping track of my session?
Looks as though I may have to revert to your URL encode suggestion...
Thanks a lot
Huw
> -----Original Message-----
> From: William Kaufman [mailto:[EMAIL PROTECTED]]
> Sent: 02 May 2001 16:10
> To: '[EMAIL PROTECTED]'
> Subject: RE: Problem with session tracking. Please help
>
>
> Are both the servers running on the same host? This sounds
> like a problem
> I've run into: since cookies are identified by host, all cookies named
> "JSESSIONID" from the same host are considered the same cookie.
>
> In my case, the servlets are running on different ports on
> the same machine.
> I can't see anything in the cookie spec (RFC 2109) which lets
> you segregate
> cookies by port, so I'm out of luck (and maybe you are, too,
> if that's what
> you're doing).
>
> If this isn't your case, try seeing what Tomcat is putting in
> the JSESSIONID
> cookie. A cheezy way to do this would be to use IE: in the security
> settings for your host, change the cookie settings to
> "Prompt"; then, when
> hitting your site, you'll get an alert from which you can see
> the cookie
> info.
>
>
> -- Bill K.
>
>
> > -----Original Message-----
> > From: Roberts Huw [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 02, 2001 7:24 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Problem with session tracking. Please help
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: William Kaufman [mailto:[EMAIL PROTECTED]]
> > > Sent: 02 May 2001 15:02
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: Problem with session tracking. Please help
> > >
> > >
> > > 1) Does your browser have cookies enabled? If not, you need
> > > to rewrite all
> > > your URLs, using HttpServletResponse.encode[Redirect]URL().
> > >
> >
> > Yes it does have cookies enabled. Supposing I decide to use the
> > above code, should I just stick it at the top of my JSP?
> >
> > > 2) Are you defining a cookie or URL parameter names
> > > "jsessionid"? That one
> > > is used by Tomcat to keep track of the session, and shouldn't
> > > be set by the
> > > servlet.
> > >
> >
> > I'm not doing either of these things.
> >
> > > 3) Does HttpSession.getId() keep returning new IDs, and
> > > HttpSession.isNew()
> > > keep returning "true" on each call to your servlet?
> > >
> >
> > No. What seems to be happening is that a browser will "steal"
> > a previously existing session while it is still owned by another
> > browser.
> >
> > I have two machines "A" and "B". "A" looks at the page and gets
> > a session id (e.g.)"A1" and isNew() returns true. "A" then
> refreshes
> > the page a number of times. session id is still "A1" and isNew()
> > returns false. Everything is wonderful. Browser "B" looks
> > at the page
> > and gets a session id "B1". isNew() returns true, but the objects
> > attached to it are the objects that were
> > associated with session "A1". If "A" then does a refresh then the
> > session id comes back as "B1" and the objects are the same objects.
> > From this point on the two browsers share the session and session id
> > and the objects attached to the session until the session is timed
> > out by tomcat.
> >
> > > As for documentation, the servlet spec goes into this
> > stuff. You can
> > > download it at,
> > >
> > > http://java.sun.com/products/servlet/download.html
> > >
> > >
> > >
> > -- Bill K.
> > >
> >
> > Thanks Bill.
> >
> > >
> > > > -----Original Message-----
> > > > From: Roberts Huw [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, May 02, 2001 3:21 AM
> > > > To: '[EMAIL PROTECTED]'
> > > > Subject: Problem with session tracking. Please help
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > We're having a problem with session tracking.
> > > > We are using tomcat pretty much "out of the box", without
> > > integrating
> > > > with apache or anything like that.
> > > > We are attaching an attribute to the session which we want
> > > (reasonably
> > > > enough) to be "per session".
> > > > We are then sending requests for information to tomcat
> > from several
> > > > different client machines (sometimes logged on as the same
> > > > user, sometimes
> > > > as different users, sometimes using Netscape, sometimes using
> > > > IE). All
> > > > machines are running Windows NT4.0.
> > > >
> > > > What we are finding is that the Session objects are being
> > > > indiscriminately
> > > > associated with the servlets. We are getting the right
> number of
> > > > session attributes created, but when we refresh the page we
> > > find that
> > > > the new request is associated with the wrong session.
> > > >
> > > > Help? Is there anything obvious we are missing? Is there a
> > > > document on
> > > > how the session management works in tomcat?
> > > >
> > > > We are using tomcat-3_3-m1
> > > >
> > > > Thanks a lot,
> > > > Huw
> > > >
> > > > **************************************************************
> > > > **********
> > > > The information in this email is confidential and is
> > intended solely
> > > > for the addressee(s).
> > > > Access to this email by anyone else is unauthorised. If
> > you are not
> > > > an intended recipient, you must not read, use or disseminate the
> > > > information contained in the email.
> > > > Any views expressed in this message are those of the individual
> > > > sender, except where the sender specifically states them to be
> > > > the views of Capco.
> > > >
> > > > http://www.capco.com
> > > > **************************************************************
> > > > *********
> > > >
> > >
> >
> > **************************************************************
> > **********
> > The information in this email is confidential and is intended solely
> > for the addressee(s).
> > Access to this email by anyone else is unauthorised. If you are not
> > an intended recipient, you must not read, use or disseminate the
> > information contained in the email.
> > Any views expressed in this message are those of the individual
> > sender, except where the sender specifically states them to be
> > the views of Capco.
> >
> > http://www.capco.com
> > **************************************************************
> > *********
> >
>
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
