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=3884>. 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=3884 SingleThreadModel servlets not pooled results in low performance ------- Additional Comments From [EMAIL PROTECTED] 2001-10-03 14:55 ------- I'll just add a bit of text from JSDK 2.0 (a.k.a. Servlet API 2.0) in regards to SingleThreadModel: ---------------------------------- In essence, if the servlet implements this interface, the servlet will be thread safe. ---------------------------------- I have started at around that time with JServ and life was wonderful. All I needed to do was to implement SingleThreadModel and not worry about anything else ever again. Right? That's where the whole thing with SingleThreadModel is actually wrong. It gives people a false promise of something that is far more complicated than implementing one interface. Java already has threading support, no need to reinvent. After thinking about all the implications that people mentioned related to SingleThreadModel, I agree with Jon - it was a bad idea in the first place (although I didn't get it for some time Jon :-) As for pool support, let me quote JSDK 2.0 again: ---------------------------------- This guarantee is ensured by maintaining a pool of servlet instances for each such servlet, and dispatching each service call to a free servlet. ---------------------------------- And compare that to Servlet API 2.2: ---------------------------------- The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet. ---------------------------------- I think someone out there realized that the pool thing does not solve the actual problem of thread safety, complicates the code and increases the memory usage of the container, so they said: let's make it simple. It does seem like someone was sending a message to container providers, doesn't it? My point here is: I also have code relying on SingleThreadModel, and I'll have to rewrite. But I think it's time well spent.
