Tuyen Tran wrote:
> 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.
>
Serialization of requests to the same session is not required to operate a
distributed servlet environment. Case in point -- Apache JServ already
supports distributed servlet engines. The current implementation sends all
requests that belong to the same session back to the same servlet engine, but
within that engine multiple requests can be handled at the same 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.
>
The cost of in-session serialization that you propose is going to be *very*
painful for your users, even if they are running only one browser window on a
non-distributed server platform. Why? Because many applications that operate
under the 2.1 servlet API will be designed so that a servlet context takes over
an entire "subtree" of the URI space. For example, things like the following
will typically be handled within one servlet context:
/myapp/index.jsp (the main menu, a JSP page)
/myapp/whatsnew.html (a static HTML page that contains "what's new"
information)
/myapp/images/logo.gif (the logo included at the top of both of the above
pages)
/myapp/images/copyright.gif (the copyright notice that is included at the
bottom of the above pages)
In this environment, the "file serving" for the static pages (static HTML and
images) will in fact be performed by a default file-serving servlet configured
for that servlet context.
Normally, when you ask for /myapp/whatsnew.html with its embedded references to
the two images (the logo and the copyright), all three requests are submitted
simultaneously (this is configurable in your browser -- Netscape defaults to 4
simultaneous requests). But, if you are serializing requests in the same
session, then these three requests get serialized! The net effect -- your user
sees much slower response times.
>
> 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.
>
Synchronization of application level data objects is an application level
issue, not a server problem. Servlets and JSP pages operate in a multithreaded
server environment. The principles about what and when to synchronize are easy
to learn and apply, and should not be built in to the server that doesn't know
which of your objects needs protection and which do not.
Askling that the server to "protect you from yourself" by serializing requests
to the same session is like buying a steak knife but covering up most of the
blade with rubber -- you can still (slowly) cut the meat, but you're not so
much at risk for cutting your finger. For myself, I'd rather learn to use the
knife safely so I can take advantage of its abilities.
>
> Tuyen Tran
>
Craig McClanahan
===========================================================================
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".
