Is Servlet threadsafe ?

[nagraj patel]

i know this answer not? but one of my interview this question is asked

[Bear Bibeault]

Which servlet? It depends how the servlet is written.

[nalla srinivas]

yes

[K. Tsang]

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). By default, servlets are multithread apps.

[M Mohile]

Please refer https://coderanch.com/t/473015/Servlets/java/Servlet-thread-safe.

[Bear Bibeault]

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.

[Ulf Dittmer]

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.

[shivam singhal]

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..

With Regards
SHIVAM SINGHAL
OCPJP - 82%
OCPJWCD - 97%

[Bear Bibeault]

Ulf Dittmer wrote:Like everything, synchronization can be misused, but there's nothing wrong with it to make an absolute statement like this true.

Agreed, my reply missed a word; I meant to say that it's a bad idea to use synchronization indiscriminately.

[Joe Ridener]

Per Chapter 3 of Core Servlets:

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

synchronize(objectYourConcernedAbout)
{
//operations to be performed on this object

}

within a method.. the same as any other application.

[nagraj patel]

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.

yes Bear,
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 ?

[Ulf Dittmer]

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?

[William Brogden]

we can make threadsafe by using SingleThreadModel

Not true - having a single instance per request Thread does not prevent an inept programmer from bad practices when accessing other objects or static variables.

The original designers thought SingleThreadModel would make it easier for programmers moving from single user desktop applications to multiuser shared applications - it didn't work out.

Bill

[Mr. Ankur Garg]

nope.. because it may have session attribute,
context attribute which can live for multiple
request in which case attributes may become
inconsistent.

[Surapuraju Venkatakishor]

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.