Tuyen Tran wrote: > The JSP 1.0 spec is very explicit in stating that the JSP user has to do explicit > synchronization when manipulating session objects. This is because two > threads holding the same user session id maybe executing on the page at the > same time. (This could happen if the user interrupted a long running > request, or if the user cloned the initial browser such that they have two > browsers opened with the same session id.) > > I believe that requiring JSP users to be aware of syncrhronization issues > for something as prevalent as session objects raises the bar for the type of > user JSP seems to be geared at. I should point out that ASP serializes > requests having the same session id, so that an ASP user only has to deal > with synchronization issues for global objects. > > I also think that not serializing requests holding the same session id > violates the "principle of least suprise." Sessions are unique to users and > it's natural to model an application such that a servlet is handling at most > one request at a time from the user. I agree. Synchronizing on the session would only very infrequently cause blocking. And those (advanced) users who are multi-threading their session should be able to tolerate such a wait. > In the majority of cases, the JSP user has to write synchronization code > anway, so why not push this off the engine? I understand though that this is > a hard flexibility/ease-of-use tradeoff... Since a user is able to directly access all session-contained objects, it seems like the synchronization would be a little tricky to 'build-in' or generate in code. Since a user can grab a session-contained object at any time and modify it at will, where would you put the synchronization? It seems like any object you stored in a session would have to be thread safe to be completely robust.
begin:vcard n:Cobb;Christopher tel;cell:703-909-7550 tel;fax:703-648-7475 tel;work:703-648-6725 x-mozilla-html:TRUE org:Powerhouse Technologies, Inc. adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:SW Architect fn:Christopher Cobb end:vcard
