Not true. In order to write thread-safe servlets, you need explicitly make it thread-safe by either synchronizing the code block or implement the SingleThreadModel (which I think is deprecated). By default, servlets are multithread apps.
Bear Bibeault wrote:It's a very bad idea to [...] use synchronization
No. Like everything, synchronization can be misused, but there's nothing wrong with it to make an absolute statement like this true. It's one of several features in Java to make concurrency work. I would agree to something like "it's a bad idea to synchronize your doGet and doPost methods", because then you'd end up with serialized execution.
Java concurrency (and especially so in web apps) is a tricky -and important- subject, though. I recommend that anyone should work through a good book like Oaks/Wong or Goetz et al.
Servlets are composed with lots of things like..
1. Request scope, Context scope , Session scope
2. Instance variables , local variables
so, it depends on you..weather to make your servlet thread safe or not..
following things you have be in your mind while designing a Thread Safe Servlet
1. Mostly try to use Local variables.. as they are thread safe.. while instance variables are not
2. try to pass control and data in via request scope.. because its thread safe
* Yeah, Single Thread Model can basically synchronise your full servlet.. and it is not a GOOD idea , as due to this your servlet can process one request at a time, which is BAD .. it will leads to Delay in request processing when your site is rising up with large hits..
OCPJP - 82%
OCPJWCD - 97%
Normally, the system makes a single instance of your servlet and then creates a new
thread for each user request. This means that if a new request comes in while a previous
request is still executing, multiple threads can concurrently be accessing the
same servlet object. Consequently, your doGet and doPost methods must be careful
to synchronize access to fields and other shared data (if any) since multiple
threads may access the data simultaneously. Note that local variables are not shared
by multiple threads, and thus need no special protection.
I think that should answer your question.
Simply put... the same as any class multiple threads can access these applications. If you they share resources you may want to consider calling locks on these objects to perform operations on them by using synchronized methods or the
//operations to be performed on this object
within a method.. the same as any other application.
Joined: Feb 16, 2013
Bear Bibeault wrote:
K. Tsang wrote:
nalla srinivas wrote:yes
Not true. In order to write thread-safe servlets, you need explicitly make it thread-safe by either synchronizing the code block or implement the SingleThreadModel (which I think is deprecated).
Also not accurate. It's a very bad idea to either use synchronization, or to use the deprecated SingleThreadModel.
Rather, the servlet needs to be written in a thread-safe manner. 99% of that is avoiding instance variables.
Servlets are by default not threadsafe we can make threadsafe by using SingleThreadModel or using synchronizing code block.again my question for you how to make servlet garbage collected explicitly ?
Joined: Mar 22, 2005
What do you mean by "make servlet garbage collected explicitly"? All objects are eligible for GC once there are no longer references to them. At which point they actually do get GCed is beyond your control, and shouldn't matter anyway. What are you worried about?
Servlets are not Thread Safe. Servlet instances are inherently not thread safe because of the multi threaded nature of the Java programming language in general. The Java Virtual Machine supports executing the same code by multiple threads. This is a great performance benefit on machines which have multiple processors. This also allows the same code to be executed by multiple concurrent users without blocking each other.
Imagine a server with 5 processors wherein a normal servlet can handle 500 requests per second. If that servlet were threadsafe, then the web application would act like as if it runs on a server with 1 processor wherein the servlet can handle only 100 requests per second (okay, it's not exactly like that, but you got the idea).
If you encounter threadsafety issues when using servlets, then it is your fault, not Java's nor Servlet's fault. You'd need to fix the servlet code as such that request or session scoped data is never assigned as an instance variable of the servlet.