And tomcat implements option 1 or 2? On Thu, 2003-01-23 at 09:36, Daniel Brown wrote: > 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]> > --
Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universit�rio Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
