Is Servlet threadsafe ?
posted 5 years ago
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.
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.
K. Tsang OCPJP7 OCMJEA6
posted 5 years ago
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.
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.
posted 5 years ago
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.
-
1
-
-
-
-
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.
posted 5 years ago
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%
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%
posted 5 years ago
Agreed, my reply missed a word; I meant to say that it's a bad idea to use synchronization indiscriminately.
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.
posted 5 years ago
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.
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
Greenhorn
Posts: 18
posted 5 years ago
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 ?
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
Rancher
Posts: 42975
76
posted 5 years ago
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
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
posted 5 years ago
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.
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.
|