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 11:59:52 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 mats.lofkvist@polopoly.com  2001-10-03 04:59 -------
First, let me clarify that my arguments are mainly
for the servlet SingleThreadModel interface, the JSP
'isThreadSafe="false"' declaration I can do without.


It seems like you have two major arguments,

1: many users don't understand how STM works and

2: it doesn't solve any real problems.


The first one is a documentation and education problem imho.
(Maybe removing the JSP 'isThreadSafe="false"' declaration
partially solves this problem. No doubt naming it 'isThreadSafe'
has contributed to the confusion.)

Note also that the assumption that there exists only one instance
of a (non-STM) servlet is broken anyway in any real world
installation using more than one web server and servlet engine.


For the second one, we have a servlet library providing different
kinds of functionality for JSPs using our product. The servlet
library is a small tree of classes. The functionality provided
consists of both methods and members. The JSPs extends a servlet
to import the wanted functionality.

SingleThreadModel is used to make this scheme work when
a servlet implements members with request specific data.

These members can be replaced with access methods, but for
all but the most trivial cases the access method now
needs to store the computed information in the request scope
instead (this is just an optimization for read-only data,
but absolutely necessary for read-write data).

Storing the data in members simplifies the code internally
but the main reason we use it is that it provides a simpler API
for our clients (implementing JSPs). Adding members adds
implicit objects that can be used directly in the JSP just as the
default implicit objects ('request', 'response', 'out' etc).
This is a much more seamless extension of a standard JSP than
possible with access methods.

Mime
View raw message