I started this thread on the servlet interest list, but I will continue it
here because I think it has more ramifications for JSP users. 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.
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...
Tuyen Tran
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
