tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Brown" <>
Subject RE: Using SingleThreadModel under tomcat
Date Thu, 23 Jan 2003 11:36:20 GMT

Here's a starter:

Normally, the servlet container maintains only one instance of each servlet,
(one instance per servlet per JVM is required by the servlet spec. in a
non-distributed environment) and passes all requests received concurrently
through the service method of that instance.

If, however, the servlet implements SingleThreadModel, then the container
has two choices:

1. serialise all requests through the single instance
2. create a pool of servlet instances, and share out requests amongst the
pool, as each pool member becomes free

Option 1 has an obvious performance penalty, if your application ever has
more than one concurrent request.

Option 2 requires more server resources for the extra objects created, more
processing to manage the pool, and, as the number of concurrent requests
increase, will end up either in poor performance, if the container limits
the pool to a certain size, and forms a queue of new requests; or poor
performance and then lack of service as the container runs out of memory.

Note also that SingleThreadModel doesn't buy you very much - although you no
longer need to worry about synchronising access to instance variables, you
still need to handle synchronisation of external resources, static
variables, sessions, etc., as you can still have more than one request
executing concurrently, just in different instances of the same servlet.



> I have a stateless servlet application in which I am considering
> implementing SingleThreadModel. I note from the archives a number of posts
> which suggest that implementing SingleThreadModel will impose a
> performance
> overhead when running under tomcat. Could anyone provide me with a
> explanation of how this performance impact comes about and (in relative
> terms) the magnitude of this impact versus the potential impact of using
> synchronisation blocks to ensure thread safe code ?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message