Great analysis and elaboration! Although I am not the one that wants everything "synchronize always". What I really expect is to get the thing done to the best possible. MT issue fix is always various, and not simple/easy to get to the best.
We should appreciate Chuck's knowledge of the Request class and the ParameterMap class - that has guided us to do the right thing at the app level. Fixing the MT issue at the low level may not always be a good idea. I think we have done a very hard enough twist. We can pretty much close this case for Tomcat now - Tomcat has done the right thing throwing the exception effectively if the app does not synchronize thing properly, or storing thing in the wrong place. Tomcat should not have any further fix/synchronization for such a buggy case. Hope Gael can fix his app happily... Dong -----Original Message----- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Wednesday, 13 December 2006 3:36 PM To: Tomcat Users List Subject: RE: Multi processor issue > From: JiaDong Huang [mailto:[EMAIL PROTECTED] > Subject: RE: Multi processor issue > > What I have been saying is that we should reconsider very > carefully whether there should be any enhancement in Tomcat. > From the Tomcat code you dug out, there is something not > quite perfect, in term of MT safe while initializing. Absolutely wrong. There is nothing incorrect about the code in either the Request class or the ParameterMap class; it fulfills every aspect of its specification. Changing the default behavior of the Request class to be synchronized on its get/set methods would be completely inane. > One of your posted messages did state that it is valid for > two threads to access/operate on the ParameterMap once it > has been established. Yes - with a big caveat. Any application doing so must provide its own synchronization to insure the integrity of the Request object (and embedded ParameterMap). In this case, the application has NO intention of using two threads on one Request - it simply has a bug in it. If we were to apply your "synchronize always" approach to software development, we'd need a lot better performance out of the hardware than Moore's law expects in order to keep up. Nor would it solve very many problems, including this one. Think about it - what would have happened if the Request object did have synchronized methods? The underlying flaw in the app that is causing one thread to lose track of its own Request and latch onto another would have gone undetected - except for some client somewhere not getting the expected response, but instead seeing someone else's output show up. Simple synchronization does not address the real problem here. > So, it may be pretty hard and confusing what the app developer > should be doing at the upper level. It's not really, IF you take time to read the specs - but few do. Admittedly, there are a lot of things that should be studied, and project deadlines rarely take that into account. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
