> 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...
It also has serious performance implications. Acquiring locks is
quite expensive, and for many uses it's not required. For instance,
read-only beans that initialize themselves at once when the session
is created would never need synchronized access, so doing it to be on
the safe side would slow things down for no purpose.
Rod McChesney, Korobra
Tuyen Tran wrote:
>
> 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".
===========================================================================
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".
