DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851 SingleThreadModel ignored ------- Additional Comments From [EMAIL PROTECTED] 2001-09-30 17:37 ------- After reading the source for TC 3.3, I can now see I was totally wrong about the pool approach. There are comments about it in the code, but it doesn't seem to be implemented. JServ used to use the pool approach (as in: good old JServ!), so I thought this must be the case in TC as well. I missed one minor detail here: JServ and Tomcat have nothing to do with one another... I have found this code snippet in ServletHandler.java of TC 3.3: -------------------------------------------------------- if (servlet instanceof SingleThreadModel) { synchronized(servlet) { servlet.service(reqF, resF); } } else { servlet.service(reqF, resF); } -------------------------------------------------------- which suggest that during the execution of service(), servlet is synchronised for SingleThreadModel. This is a piece of code from JspServlet.java: -------------------------------------------------------- if (servlet instanceof SingleThreadModel) { // sync on the wrapper so that the freshness // of the page is determined right before servicing synchronized (this) { servlet.service(request, response); } } else { servlet.service(request, response); } ------------------------------------------------------- which also suggests syncronisation for SingleThreadModel. Can someone that understands this whole thing a bit better comment. I think we should be very clear in release notes of TC 3.3 if it doesn't comply with parts of the spec. >From the code, it seems to be compliant...
