Kevin said:
> Another question about threading. I think this is something that definitely
> needs to go into the FAQ.
Comments welcome...
FAQ Addendum - Threading in Servlets
(Or What A Tangled Web We Weave)
Are servlets thread safe?
Servlets are only thread safe to the degree that you, the programmer,
manage them in a thread safe manner. Servlets by default may be assumed
to be running in a multi-threaded environment. It is the responsibility
of the programmer to ensure that all access to resources that could
result in concurrency problems be properly synchronized.
Recall that in servlets member variables will be accessed by all running
instances within that thread, which is a language legalese way of saying
that:
class MyServlet {
String login = null;
String password = null;
public void doPost (...){
login = request.getParameter("login");
password = request.getParameter("password");
...
}
...
will almost undoubtedly misbehave. Note that if the login and password
variables were declared within the method, this would not become an
issue.
Although thread safe programming is not solely a servlet topic and is
thus beyond the intended treatment of this FAQ, here are a couple rules
of thumb regarding the writing of thread safe servlets:
1. Pretend that member variables are static. While it would be
exceedingly foolish to actually depend on a servlet's member variable
being static (as you are not *guaranteed* to hit the same instance of a
servlet), keeping this possibility in the back of your mind may
eliminate some problems. You might even want to go so far as to declare
member variables of servlets as static.
2. Ensure that your objects are thread-safe. Unless you ensure that all
of your objects exist only as instance variables within a thread, you're
going to have to make sure that critical areas in your objects are
marked synchronized. This is especially important in a multideveloper
environment where people may assume your contributions will be thread
safe. Remember that simply declaring a method or block synchronized is
not sufficient, and that two level locking is a much stronger method.
Several design patterns can help here - things like Mediators,
ObjectPools, and so on.
3. When necessary, implement SingleThreadModel. Although this last
method would seem a prime candidate for the Throwing the Baby Out With
the Bathwater Award, there may be cases where you must remain so
paranoid about synchronization that it is worth while to consume more
resources and limit user concurrent access. 9 times out of 10, though,
what you really need to do is extract the offending code from the
servlet and put it into one or more objects who then manage their own
synchronization.
--
Within C++ is a smaller, cleaner language
struggling to get out.
It's called Java.
Thomas Moore
[EMAIL PROTECTED] Home Account
Software.Engineer [EMAIL PROTECTED]
phone://732.462.1880:268 NJ Patterns Group Home Page
employer://Celwave, RF http://members.home.net/twmoore/cjpg
___________________________________________________________________________
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
