Servlets are not thread safe. If you want to make it Servlet as Thread safe, you can implement SingleThreadInterface which is a blank Interface there is no methods (this is not recomend method, because it could slow the performance of your page) or you can synchronize methods by using synchronized keyword. Anyway, this is quite basic question, try to use google in this case, you will find a lot of pages with a full story about this .
The SingleThreadModel interface is deprecated and due for removal. The problem is that it causes a performance hit while only providing the illusion of thread safety.
Assume that multiple threads will be able to access your servlet at any time (except during initialisation). Therefore local variables are safe but instance variables are not. The Request and Response are (typically) thread safe but any other shared or global instance such as Contexts, sessions etc are not and must be treated with care.
Deprecated from Servlets 2.4 (see the link to the interface and read the API)
There is no simple answer to making a Servlet thread safe. Making sure you don't have any instance or mutable static variables is a start, local variables are a safe replacement.
The full answer is that it is no longer a Servlet based problem but a threading problem.
If you're at all serious about concurrency in Java -and in these days of multi-core CPUs, multiple CPUs per machine, and multi-threaded environments like servlet containers and application servers, who can afford not to be?- I'd advise to work through one of the eminent book on the subject - either "Java Threads" by Oaks/Wong or "Java Concurrency in Practice" by Brian Goetz et al.
A servlet should not override the service method, so you can't really synchronize that. Note that synchronizing the entire doGet or doPost methods effectively destroys concurrency for this servlet; that may be OK if there are multiple servlets and the one in question is only a small part of the web app, but generally you don't want to do that.
It might be OK to synchronize small, appropriate sections of those methods.
Really that is a nice article to understand. Some times before I've had some thread sharing problem and I've solved using inner class to initialize variables that are needed. This stops thread sharing of instance variables and it's up to your requirement.
No pain, No gain.
OCJP 1.6, Liferay Certified Developer 6.1
While that article demonstrates the various approaches to thread safety, I don't particularly like the example. You wouldn't use synchronization for protecting an int, you'd use an AtomicInteger instead.
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop