On Fri, 14 May 1999, Lauren wrote:
> At 05:20 PM 5/13/99 , jon * wrote:
> >
> >No "guru" here in his/her right mind would suggest using STM to
> >implement a servlet.
>
> So it is totally useless for any servlet devo work and *no*
> knowledgable person would suggest using it? Sun made a mistake in
> including it in their servlet API?
>
> Really, I appreciate the comments, I am just a newbie after all and
> very willing to learn - I just am very wary when people make
> absolute statements.
>
>
> >Ok, I see why they suggested using STM, but really, you are going
> >to end up biting yourself in the foot for having used it. Learn how
> >to use a connection pool, it isn't that hard and dump STM.
>
> Is there a resource you could point me to that would tell me why the
> STM should not be used for servlet devo work, or maybe you could
> explain for my benefit?
I'm inbetween a "newbie" and a "guru" :-), so let me add my impression
of some of the issues here and see if it helps any.
I'll start out by summarizing my impression of STM: It's a simplistic,
overly general way of dealing with multi-threading, which may not even
do what you want/expect in certain situations, and which may yield
decreased performance. It is a poor substitute for understanding the
underlying issues involved, and coming up with a better, cleaner
solution.
I think you need at least a somewhat deeper understanding of
multi-threading and what STM is, how it works, and how it is generally
implemented to appreciate this.
Multi-threading, in the servlet context, simply means that multiple
threads may be working on your servlet instance (normally there is
only one) at the same time. The simplest area where you can see that
this can be problematic is when the servlet has class (i.e. static)
and/or instance variables (since there is normally just one instance
of a servlet, these are somewhat similar). The problem is that,
after such variables are set by one thread, another thread may come
along and change their values before the first thread has a chance to
use them.
What STM does is ensure that only one thread will operate on a servlet
instance at any one time. With this, you need not worry about a
second thread changing the values of class/instance variables out from
under the first thread.
So why is this not necessarily good? Well, first of all, there is a
performance penalty. Only one thread will be able to go through the
servlet instance at a time, so any other threads that come along will
have to wait for the first to finish -- in some sense, things run in
serial instead of parallel. One thing servlet engines do to get
around this is to create a pool of servlet instances, and if one
instance is busy with a thread, one of the other instances will be
used. This eliminates/reduces the performance penalty. (One time
previously when I had mentioned this performance penalty, someone said
that the way servlet engines implement STM, there isn't much/any of a
performance penalty, so I'm not sure how significant this is.)
However, having multiple servlet instances can lead to some unexpected
behavior. First of all, class and instance variables are no longer
handled the same. Instances variables will be multi-thread safe, but
class variables won't. Further, if the servlet operates on some
resource external to the JVM (like a file on the server or a DB that
isn't multi-thread safe on its own), those resources will not be
protected, since STM does not do any kind of cross-instance
protection.
So, someone could slap an STM on their servlet and think they're 100%
multi-thread safe, but that isn't the case. You really need to look
deeper to see if there are any potential problems. And if you're
doing that, you might just as well determine where the potential
threading problems are in your servlet, and either change the design
so that they are not problems, or synchronize things down at the
lowest possible level (STM is in some sense synchronizing at the
servlet instance level).
Now, some may say that they're doing relatively simple things and that
hence STM works fine for them, and that they're not in a high-usage,
speed-critical environment, so that some performance penalty isn't a
big deal. Fine, STM may be fine for those situations. But it is not
a panacea, and you might just want to get into the habit of avoiding
it and designing/writing things more cleanly to begin with.
Apologies if this was too long and too simplistic, but hopefully it
helped someone. Note that these are not the only issues with STM.
Corrections/elaborations/comments welcome.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
