SingleThreadModel behavior in Websphere

As SingleThreadModel interface is already deprecated in Servlet 2.4 specification, it is still a need sometime to utilize this interface. Of course, good programming practice would avoid the use of instance members and class members in the servlet (or whatsoever class that supports concurrent multithread invocations). I have a situation where the API is provided by third party vendors and the API seems don't behave properly in multithreaded environment.

Referring to the Servlet specification, there are 2 ways that the container might handles the servlet that implements SingleThreadModel. First, the container create only one instance to serve all requests. All requests to the container will be handled in sequence. Second, a number of instances will be created and place into the pool. Each request will be assigned a servlet instance. It is not guaranteed that each request will be assigned a new instance. Instances in the pool will be reused.

Websphere Application Server handles SingleThreadModel by following the second approach. Although the hardware requirements increased to support this requirement, it is better than the first approach where user response time (waiting for their turn) is unacceptable.


IBM: Websphere Best Practices