Forums Register Login

SingleThreadModel

+Pie Number of slices to send: Send
Hi All,

According to spec (for SingleThreadModel)

"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?

Thanks
Arnab
+Pie Number of slices to send: Send
Hi Arnab,

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

Marco
+Pie Number of slices to send: Send
SingleThreadModel is used to protect instance variable from multiple thread.

In your case you have to synchronize the ServletContect instance to protect the context attribute provided that the code manipulate the attribute also present within the synchronized block.
+Pie Number of slices to send: Send
Thanks Siva and Marco
+Pie Number of slices to send: Send
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.

Marco
+Pie Number of slices to send: Send
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??


+Pie Number of slices to send: Send
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).

Marco
+Pie Number of slices to send: Send
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"

Thats why i was asking about that
+Pie Number of slices to send: Send
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.

Marco
Doe, a deer, a female deer. Ray, a pockeful of sun. Me, a name, I call my tiny ad ...
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1467 times.
Similar Threads
How to Interpret SingleThreadModel query( Drop your opinion)?
Single Thread Model
Question regarding SingleThreadModel
how many times init() method gets called
Is Sessions thread safe if servlet implement SingleThreadModel interface ?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 19, 2024 01:52:53.