Adrian, 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. HTH, Dan. > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
