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 ([EMAIL PROTECTED]) :::::::::::::::::::::::::::::::::::::::
>
Craig McClanahan
-- --------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
