Thanks Remy, I knew something as major as this would have surfaced and been fixed eons ago. However there is something here.
After more brain-racking, a vital piece of the jigsaw has come to light. The app was updated at a suspiciously similar time to when the problem was reported. We use an ant script which does a <stop><extract><start> type thing. Is it possible that after the re-start duplicate ids for the "persisted" and restored sessions are being created? -----Original Message----- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: 18 September 2003 12:05 To: Tomcat Developers List Subject: Re: Duplicate Sessions Tomcat 4.1.24 Andy Chapman wrote: > I have a deployed web app with a medium size user base (~500) which > recently went live. The app relies on the session to retrieve user > information. The session usage is simply to store a couple of ids > (Strings) and retrieve them from the session to lookup data. This all > works perfectly with a small user base (~20) but horror of horrors, > when loaded, people are seeing other peoples data. I have trawled > through my code and, although as ever keeping an open mind, can only > imagine this is happening if SESSIONID's are being duplicated and > therefore the data is being overwritten by the "other" user(s). > > I remember a thread in January about duplicates in 4.1.18 "Duplicate > session IDs are *common*", but can't find anything in the bug > database. Does anyone know if this ever was a problem or is still a > problem in 4.1.24? What puzzles me is the relatively small number of > concurrent users which cause this to happen. > > I am attempting to reproduce the problem in a sterile environment now, > any thoughts, help or fixes :o) would be greatly appreciated. A race condition in the session recycling code had been identified in 4.1.18, which could cause that (one session object could have been added more than once in the recycled session list). As a result, session recycling was disabled in 4.1.24 (and is removed from 5.0.x). No such issue has been found in 4.1.24, and we haven't had any report on such a behavior since 4.1.24 was released six months ago. I recommend you investigate more. Remy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
