SingleThreadModel

[Thomas Roeblitz <th...@infopark.de>]

Hi,

I'm wondering how Tomcat (Versions 3.1 and 3.2) implements the
SingleThreadModel. I was observing (v3.1) the case that parallel
requests were executed concurrently for the very beginning, but
later not. This behavior has been reported by some other people.

Regarding version 3.2.1 I found a comment that the implementation
uses a synchronized service-method.

Does anybody know something about the actual implementation? How
about further releases, is there a plan to provide one servlet
instance per thread which executes a SingleThreadModel-object?

Are there other Servlet-Containers which implements it in the
way that every thread gets its own servlet instance?

Thanks for your help. Any comment would be helpful

Thomas

Re: SingleThreadModel

[Milt Epstein <me...@uiuc.edu>]

On Mon, 23 Apr 2001, Thomas Roeblitz wrote:

> Hi,
>
> I'm wondering how Tomcat (Versions 3.1 and 3.2) implements the
> SingleThreadModel. I was observing (v3.1) the case that parallel
> requests were executed concurrently for the very beginning, but
> later not. This behavior has been reported by some other people.
>
> Regarding version 3.2.1 I found a comment that the implementation
> uses a synchronized service-method.
>
> Does anybody know something about the actual implementation? How
> about further releases, is there a plan to provide one servlet
> instance per thread which executes a SingleThreadModel-object?
>
> Are there other Servlet-Containers which implements it in the
> way that every thread gets its own servlet instance?
>
> Thanks for your help. Any comment would be helpful

I believe some/most servlet containers do implement a pool of servlet
instances when a servlet implements SingleThreadModel.  But I don't
know about Tomcat.

But since you say "any comment" :-): DON'T USE SingleThreadModel!
There has been a lot of discussion of SingleThreadModel on Sun's
servlet-interest list, and the strong consensus is that it's bad to
use it -- it's misleading, because it doesn't really eliminate all
threading-/concurrency-related problems, and it causes a performance
hit.  The best thing is to just bite the bullet, learn what you need
to know about threading/concurrency, design your system to eliminate
threading/concurrency problems as much as possible, and when
unavoidable, use synchronize on the smallest block possible.

Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu