This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
"Ensures that servlets handle only one request at a time. This interface has no methods. If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet"
I have a question on
"or by maintaining a pool of servlet instances and dispatching each new request to a free servlet"
Suppose I have a servlet which does the following (servlet implemented SingleThreadModel)
If container is maintaining pool of instances and the container assigns separate request to separate available instances from the pool, how can the above code thread safe?
with the SingleThreadModel the code is thread-safe because there is only a single thread accessing the Servlet code at a time - just as the name suggests. Without multiple threads running concurrently there's no need to worry about typical concurrency issues.
Unfortunately the SingleThreadModel is not of much use in production environments, even though it would be the easiest way to avoid concurrency problems
But be aware that it's easy to overuse the ServletContext and synchronization. Of course you should use synchronization where needed but if you make too much data application wide accessible (= ServletContext) and synchronize access to this data then it can easily become the bottleneck of the application because requests could get serialized if you use naive synchronization for all data. If really all requests are serialized you basically end up with another form of a single threaded model.
I was trying out this STM ...
I implemented the STM for a servlet class and i noticed the there are two objects created when a request for the servlet is invoked (i used the initialization block to count the objects ).
So i wanted to know how many objects are created if a servlets class implements STM. How do i know that ?? Where in the TOMCAT it is defined??
The STM is all about the threading model as the name says. It only guarantees concurrent access to a Servlet by a SINGLE thread. But it doesn't make any assumptions about the number of instances of any Servlet the container might create.
In Tomcat you can tune the number of available threads when not running with the STM but I'm not aware of any configuration options to force creation of a specific number of Servlet instance. Anyway, that's the reasoning behind all the Java specifications. You should only rely on the facts the spec guarantees but you shouldn't make any additional assumptions on a concrete implementation (like Tomcat is for the Servlet API).
Joined: Oct 04, 2009
I agree that that STM does guarantees concurrent access to a Servlet by a SINGLE thread , but the servlet spec says..
"The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet"
OK, now I see. Unfortunately I have no idea how Tomcat implements this scenario. I think you could have a look at the source code of Tomcat to get an idea how exactly it works internally. A good starting point would be the "Wrapper" interface and its implementation "StandardWrapper". On the other hand the SingleThreadModel is marked as deprecated anyway beginning with Servlet API 2.4. Maybe it's just not worth to worry about it too much.