Another reason I'd like to see requests serialized is to make the JSP user's
life easier in a distributed servlet environment. If there is a requirement
that a servlet only processes one request from each "user" at a time, then
the session semantics in a servlet cluster are clear: the cluster must
serialize requests holding the same session id such that only one such
request is processed in the cluster at any one time.

As for the cost of synchronization (in a single servlet environment), I
don't believe it's that high. Entering the monitor will cost some cycles,
but the cost is bearable: witness the number of methods in Java.lang.Vector
that are synchronized. Java's lack of COM-ish "threading models" (which I
think is a good thing) means that the VM is already spending a lot of time
on synchronization when it doesn't need to.

One implementation approach (again only in a non-distributed environment)
would have the servlet engine synchronize on the HttpSession before it
enters the service method. By convention, any code operating outside of the
service method would also synchronize on the HttpSession before grabbing
session-contained objects. Perhaps this behavior could be controlled by a
page directive.

Tuyen Tran


----- Original Message -----
From: Christopher Cobb <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 1999 2:51 PM
Subject: Re: Serializing requests


> > 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.
>
>
>
>
>

===========================================================================
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".

Reply via email to