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=7681>. 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=7681 Tomcat does not work properly in multithread environment Summary: Tomcat does not work properly in multithread environment Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Servlet & JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This bug exists also in version 4.01, so it is much possible it exists in all 4.x versions. I found that Tomcat has a quite serious bug, that causes it not working correctly when more than one thread is processing requests. The bug appears when the welcome file is a FRAMESET definition file, which does not access session object nor use beans - the first access of session is by session-scope bean definition in pages, that are loaded in frames from this frameset. Now, since browser makes requests for frames concurrently, each frame is usually processed by different Tomcat thread. And there is a problem: if two frames uses the same bean (of session scope), it often gets initialized twice !!! (it usually happens when the bean communicates with database during init, or makes other time-consumpting operation). The workaround is to make welcome file access the session (e.g. by setting some attribute or by reading session ID) - then the bean gets instantiated only once. The reason for this bug is in servlet generated from JSP: there are parts that are synchronized on "session" object - it does not make any sense, since session is an instance of StandardSessionFacade, which is a page-level object - it is created as new object on every page, and every time the page is accessed (just print it on System.out - every time, different address is printed); it would make sense if the synchronization was on HttpSession object encapsulated by StandardSessionFacade. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
