SingleThreadModel

[Srinivas Pitta]

Hi,

When a servlet implements SingleThreadModel, how many instances would this servlet have? In HeadFirst SCWCD book, they have mentioned that one instance would be created per request.

Can someone explain how it creates a new instance per request. And i would appreciate if they could explain with an example. For an instance, when 3 requests comes to a servlet that implements SingleThreadModel and the number of instances and number of threads that would be active at a given time.

Thanks for your time.

Regards,
Pitta.

[Rahul Bhattacharjee]

I think this has been left to the implementor of the servlet engine.A vendor might decide to make one servlet per request or can make only one request for a servlet and then allow another after the completion of the first request.

[sven studde]

For an instance, when 3 requests comes to a servlet that implements SingleThreadModel and the number of instances and number of threads that would be active at a given time.

What's your best guess?

Can someone explain how it creates a new instance per request.

This question made me wonder how the container makes different threads for a servlet when the HttpServlet class does not implement Runnable nor extend Thread. I looked at the super classes of HttpServlet and they don't appear to extend Thread or implement Runnable either. Anyone?
[ October 19, 2006: Message edited by: sven studde ]

[vishwanath nadimpally]

sven studde
I looked at the super classes of HttpServlet and they don't appear to extend Thread or implement Runnable either. Anyone

As far as I know, the life cycle of a servlet is controlled by the container. So I think the implementation of the container has methods that spawn a new thread for a new request for a servlet. Its a very good question, and I would like to know the correct answer too.

[vishwanath nadimpally]

I found this for tomcat :
Class ContainerBase.ContainerBackgroundProcessor
java.lang.Object
org.apache.catalina.core.ContainerBase.ContainerBackgroundProcessor
All Implemented Interfaces:
java.lang.Runnable

and ,

    
 
backgroundProcessorDelay: 
 
This value represents the delay in seconds between the invocation of the 
backgroundProcess method on this host and its child containers, including 
all contexts. Child containers will not be invoked if their delay value is 
not negative (which would mean they are using their own processing thread).
 Setting this to a positive value will cause a thread to be spawn. After 
waiting the specified amount of time, the thread will invoke the 
backgroundProcess method on this host and all its child containers. A host
 will use background processing to perform live web application deployment 
related tasks. If not specified, the default value for this attribute 
is -1, which means the host will rely on the background processing thread 
of its parent engine.
 

[ October 19, 2006: Message edited by: Ben Souther ]
[ October 19, 2006: Message edited by: vishwanath nadimpally ]

[Stan James]

If you create a new exception in a servlet (don't throw it) and print the stack trace you'll see a long chain of classes written by the container vendor. Something in that chain will be Runnable.

[William Brogden]

So I think the implementation of the container has methods that spawn a new thread for a new request for a servlet.

Since creating a new Thread is not cheap, servlet containers maintain a thread pool and assign instances as needed to respond to requests. With Tomcat you can control the maximum number of Threads in the pool.

Bill

[vishwanath nadimpally]

Originally posted by William Brogden:


Since creating a new Thread is not cheap, servlet containers maintain a thread pool and assign instances as needed to respond to requests. With Tomcat you can control the maximum number of Threads in the pool.

Bill

But with this multi-thread pool there can be pool-related deadlocks ,thread leakages too.and what about concurrency isssues, since they rely on wait() and notify() which can be tricky. How do the containers handle these?

[Stan James]

Carefully. And to keep things orderly, they discourage us from playing with threads on our own inside the container.

[William Brogden]

But with this multi-thread pool there can be pool-related deadlocks ,thread leakages too.and what about concurrency isssues, since they rely on wait() and notify() which can be tricky. How do the containers handle these?

Things are not as complex for the container as you think, for the extremely good reason that, each request Thread operates independently with its own objects for interpreting requests and creating responses.

The points of concurrency conflict are well known - for example database connections - but you the programmer have to handle them. The container may supply connection pools, etc but it is up to you to use them.

Thread leaks are possible as I know from my own mistakes. Beware of using the request Thread to access a resource that may hang indefinately.

Bill