Craig R. McClanahan Wrote:
>
> 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.
>
The JServ approach pins sessions to the originating VM and will not
fail-over sessions. More advanced distributed servlet environments will let
any VM service any request, regardless of which VM originated the session.
In such an environment, either the developer or the engine will need to
provide a distributed lock manager for sessions. On the surface, requiring
sessions to be serialize seems to be an easy way to formally transfer
responsibility for session management to the tool vendors.
>
> 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.
>
This is a very good point. Request serialization clearly cannot be enforced
for all servlets. But it *can* be enforced at the request of the client.
>
> 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.
>
I disagree with you on this point. Synchronization issues are notoriously
hard to get a handle on. "Gotchas" are numerous and subtle to boot. Without
request serialization, JSP may get a bad rap as being "hard to use."
> 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.
>
Web server applications are easier to conceptualize if requests are
serialized. My argument is that:
1) Serializing requests will be the correct thing to do in the majority of
cases.
2) Most developers expect requests to be serialized, especially if they come
from the ASP world.
I realize that such a sweeping remarks leaves me wide open, but I believe
they're true.
Finally:
3) The option to serialize requests could be turned off, if one wants the
sharp knife.
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".
