--- Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On 9/7/07, lightbulb432 <[EMAIL PROTECTED]> > wrote: > > > > I'm reading some book concurrency books that talk > about potential thread > > safety issues with HttpSession. Specific cases > follow: > > > > - When the web container passivates an HttpSession > while a user's request > > modifies it > > strange use case. why should that happen? >
Yes, to me that would be a bug. I mean, if the server were to be in the act of caching a dormant session out to disk and out of memory when a request came in there should be a lock in place, and then once it finished doing so, the lock would be released, the session would be brought back into memory, and all should be well. If not, then it simply would not work and would be bad coding...that is when you file a bug. > > - When the web container replicates an HttpSession > while a user's request > > modifies it > > Hmm.. Is it a real issue for you? > Again, if it were doing so, same as the above issue. If the server or infrastructure for clustering were doing anything related to copying out to keep multiple instances up to date I would expect concurrency to be controlled at the server and cluster level, and if not then it would simply be a bug. I don't see how it could be anything else unless the clustering support allowed you, in configurable instances, to tell it not to be so rigid and allow access to these things even when they may not yet be up to date. Then in this case you would have to know your logic well enough to know if it would be an issue or not, and would hope being rigid would be the default. > > - When multiple quick, successive requests from > the same user access the > > same HttpSession > > No problem here, at least not with 2.5 compliant > server. > My other reply was specifically about this. Wade --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]