tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
Date Wed, 03 Oct 2001 21:55:03 GMT
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 bojan@binarix.com  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.

Mime
View raw message