I suppose in a situation where a server did not handle concurrency for you in the lowest possible level the version of JSTL and EL and such things which it used could handle concurrency by wrapping such access, but this would then mean you could not access the session in regular coding practices because you would not have access to the same locks the JSP support code was using, so you as a developer would have to choose between some pure JSP versus servlet type application instead of mixing the two, and even then I don't see how you could truly use JSP as you have to access your logic and the session one way or another at some point...that or make your own session, so I don't think with the current specifications it would be possible for a server to be reliable for any real usage if it did not handle the concurrency issues itself at the lowest possible levels.
Wade --- Wade Chandler <[EMAIL PROTECTED]> wrote: > Tomcat wraps HttpSession objects underlying maps > using > java.util.Collections.synchronizedMap. There was a > previous issue in a version of Tomcat 5.0.x > something > in which this was changed, and it raised a stink, so > it was fixed again. It had to be put back to use > synchronized as the concurrency issues caused such > headaches the developer had no way to manage this > from > an application perspective. I can't imagine Tomcat > would have calls which are not synchronized to pull > a > session back from storage either. The user certainly > would not have any control over such a thing as JSP > session access can not be wrapped easily by > developers > using normal synchronization techniques. Are you > having some specific issue? > > Wade > > --- 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 > > - When the web container replicates an HttpSession > > while a user's request > > modifies it > > - When multiple quick, successive requests from > the > > same user access the > > same HttpSession > > > > Could somebody explain how Tomcat deals with the > > first two, and what steps > > web application developers need to take to avoid > > concurrency problems with > > all three cases above? Is it guaranteed that the > > passivated/replicated > > object is always a consistent view of the > > HttpSession? > > > > Thanks. > > -- > > View this message in context: > > > http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600 > > Sent from the Tomcat - User mailing list archive > at > > Nabble.com. > > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: > > users@tomcat.apache.org > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: > users@tomcat.apache.org > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
