----------
From: "Craig R. McClanahan" cmcclanahan@MYTOWNNET.COM
To: SERVLET-INTEREST@JAVA.SUN.COM
Subject: Re: Development tools
Date: Mon, May 17, 1999, 8:54 AM

I agree with Jon that STM is a bad thing.

All harshness aside, there are multi-thread issues that SingleThreadModel does
not address.  Programmers that rely on it because they don't know how (or don't
want to know how) to write multi-thread-safe code will usually get bit on one
or more of the following:

* Performance -- for toy projects, or during development, you often
    don't see this one, but it shows up when you put a multiuser app
    into production.  Partial solution -- configure your servlet engine for
    multiple instances, but this leads to the next problem.

* Information sharing -- 99.9% of new servlet authors seem to think
    that STM means there will be only one instance of the servlet, but
    that is not necessarily the case.  In particular, you solve some of the
    performance issues by telling your servlet engine to create more than
    one of them.  Even with STM, you can not rely on using instance variables
    in your class as globals.

*  Multiple users -- Even if STM solves particular programming issues
    for you, servlets operate in a multiple-user environment.  You still have
    to worry about things like two users modifying the same data at the
    same time.  You can't hide from multi-threading, and the requirement
    to properly synchronize access to shared objects.

STM encourages developers to believe that they don't have to worry about
multithreading.  This leads to disappointment and required redesigns when you
run into cases where your assumptions are violated.  Much better would be to
train new servlet programmers to program in a multithreaded manner from the
first moment.

This is where the experts have some responsibility -- we need to make sure that
the examples we create demonstrate thread safe techniques.  Servlet book
authors need to emphasize thread safety in their tutorials and explanations --
and demonstrate how to program it correctly.  Development managers need to
insist that thread-safe techniques be used on the projects they are building.
Above all, it is the responsibilty of API designers to avoid tempting people to
take the "easy" way out, without solving *all* of the related problems.

But new servlet developers have a responsibility also -- you need to commit
yourself to learning how to properly use the tools you are working with.
Otherwise, you will perpetuate the bad reputation that software developers
carry in the real world, for creating stuff that just does not work.

Craig McClanahan

----------
From: "Craig R. McClanahan" cmcclanahan@mytownnet.com
To: Java Apache Users java-apache-users@list.working-dogs.com
Subject: Re: STM Question
Date: Wed, May 19, 1999, 12:47 AM


Greg Barish wrote:

> Hi -
>
> I noticed that there is a new FAQ entry which describes STM as a "bad
> thing".   Since synchronized methods in servlets have been (in the past)
> declared as also a no-no, I would like to know what the current
> suggested design for building servlets which have high availability
> and reasonable (but sub-optimal) scalability, given the constraint that
> the servlet resource is serial in nature.
>

STM is bad, primarily because it does not solve all of the problems related
to writing servlets in a multithreaded runtime environment.  The biggest
issue is that it seduces developers into thinking they don't have to worry
... this is actually a more serious issue than the technical things that
are not dealt with.

>
> For the sake of example, suppose that I have a sequence generator
> which only responds to socket queries on a well known port.  Suppose
> that I am then hit with 20 concurrent requests for a new sequence
> number.  All servlets will attempt to use the port simultaneously,
> but one will obviously fail.
>

SingleThreadModel does not help you at all in this case, so what's the
question?  The issue here is a lack of scalability at the application level
-- and serializing the servlet that's calling is not going to improve
performance over application-level seriailization of access to your
sequence generator.


>
> Unless I use home-grown Mutex code (ie, Pier's) to serialize, what
> is the alternative to dealing with this synchronization problem?
>
> I know, I know.  A serial resource ain't gonna scale anyway.
> But there are many callers (esp autonomous clients) which are really
> quite happy to wait and _absolutely hate_ to get HTTP 500s back.
> They are more concerned with availability than scalability.
>

If it's not going to scale anyway, and if adding an artificial restriction
in what the servlet engine can do will not help matters any, what's the
point of making the restriction available?

Having STM servlets or not does not directly lead to generating request
processing errors.  In fact, most servlet engines do queue deal with
multiple simultaneous requests (even to STM servlets) by using features
such as the listen backlog queue on a TCP socket.  But there is absolutely
nothing the servlet engine can do about an application-level resource that
cannot serve multiple requests simultaneously.

STM is actually worse than that.  Most servlet engines let you compensate
for the single-threaded response handling by starting multiple instances of
the STM servlet.  For example, Apache JServ defaults to 5 instances of an
STM servlet.  But guess what ... you have now just recreated a race
condition for your serialized resource, so what's the point?  If your
application fails to deal with this correctly (and you fail to configure
the servlet instances to only create one) it is still your application that
is at fault.

>
> It would seem to me that the requests should somehow be queued.
> Mutexes can provide that queuing, but this could be made more scalable
> if the mechanism was event driven (like a conditional).  Thoughts?
>
> Apologies if I'm missing something basic here.  Feel free to blast me.
>

The basic issue is that scalability starts as an application-level
problem.  Automatic locking or synchronization at the servlet engine level
cannot solve these problems -- at best it can enable a programming
technique (using servlet instance variables for storing request-state
information) that is a trap in the long run, and will lead to a requirement
for application redesign anyway.  You are much better served by learning to
deal with multithread issues at the point of initial application design --
but STM gives new servlet programmers a false sense of security that this
is something they can worry about "later" instead of "now".


>
> --
> ::: Greg Barish (barish@isi.edu) :::::::::::::::::::::::::::::::::::::::
>

Craig McClanahan