Servlets are rightly not threadsafe, so you need to either implement SingleThreadModel which is deprecated in the latest servlet Spec. or you need to code your Servlet in such a way that it is Thread-safe.
Because for most servlets, the issue of thread safety doesn't arise. You design systems to work naturally for the common uses, but to allow programmers to do uncommon things. And since Java already has features which allow programmers to achieve thread safety when necessary, it wasn't necessary to do anything specific in the implementation of servlets. It's the programmer's responsibility to deal with it in the few cases where it is an issue.
Well, as I said there was this SingleThreadModel that could be implemented to make threadsafe, but was deprecated as it did not providing complete synchronization, it provided code level sync but then the session context, applicationcontext was not synchronized.
So the other option is the only way to get thread-safety in servlets is to code the Servlet in a Thread-Safe manner. THe JavaWorld guys have told how to do this.
You can try reading on net of what Thread-Safety means. Which you can again read here. webpage.
Joined: Aug 12, 2008
Paul Clapham wrote:Because for most servlets, the issue of thread safety doesn't arise.
Thanks for replay,
But still I have little bit of doubt regarding servlets thread safety, so why most servlets, the issue of thread safety doesn't arise.How can you say this? and what is reason behind this? please clarify my doubt.
The issue of Thread safety does not arise because each request is handled by a single Thread and this thread is the only one that has access to the request and response objects. Objects and variables which are created inside the service or doGet or doPost, etc method are only visible to the Thread handing that request.
It is the programmer's job to ensure that objects and variables which are potentially reachable by more than one request Thread are handled properly.