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 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.
