> I have only one tomcat server. The "different machines" in question
> are different client machines.
So it sounds like you _are_ running into a similar issue as I am: one
browser instance (see below) connecting to one or more servlet containers
running on the same machine. Right?
> 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.
IE will only ask once per browser instance (or process): if you start up
another IE (from a desktop icon, for instance), it'll ask again. But if you
start a new window by selecting "File/New/Window" from the menu, it's the
same browser instance, and you'll share the same session ID; and, if the
original browser window was already connected to your server, IE won't ask
again for the new one.
And note that, if you disable per-session cookies and enable persistent
cookies in your browser, the cookies will now go to disk and be shared among
all browser instances: you'll once again run into servlets clobberring your
cookie, but opening new browser instances won't help you anymore.
-- Bill K.
> -----Original Message-----
> From: Roberts Huw [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 8:49 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Problem with session tracking. Please help
>
>
> 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
> **************************************************************
> *********
>
