> -----Ursprüngliche Nachricht----- > Von: Craig McClanahan [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 7. September 2005 00:59 > An: Struts Developers List > Betreff: Re: How ThreadSafe are struts-taglibs, or do we want > them threadsafe? > ... > When I was working on Tomcat a couple years ago , I can vouch > for the fact that it did this correctly. I haven't looked at > the latest version's sources, but I can't imagine they would > have broken this -- it's too fundamental. >
Sorry Graig, I looked into the source; yes, it has your name in it, and no, it is not thread safe (jakarta-tomcat-5.0.25-src) class org.apache.catalina.session.StandardSession ... * @author Craig R. McClanahan * @author Sean Legassick * @author <a href="mailto:[EMAIL PROTECTED]">Jon S. Stevens</a> * @version $Revision: 1.43 $ $Date: 2004/04/01 20:18:15 $ ... public class StandardSession implements HttpSession, Session, Serializable { ... /** * The collection of user data attributes associated with this Session. */ protected HashMap attributes = new HashMap(); ... public void setAttribute(String name, Object value) { ... // Replace or add this attribute Object unbound = attributes.put(name, value); ... } ... public Object getAttribute(String name) { if (!isValid()) throw new IllegalStateException (sm.getString("standardSession.getAttribute.ise")); return (attributes.get(name)); } It is using HashMap, and the HashMap isn't synchronized, nor it is threadsafe. Neither the StandardSession nor the Facade are synchronizing anything or protect the underlying HashMap from parallel modification. What actually happens, if you write to the Session (and therefor into the HashMap) simultaneously in multiple threads, you get to the point where you have a HashMap whose entries got circularly linked, and any thread using a get() on such a HashMap will spin forever chasing its tail (quoted from Larry Isaacs). If you have any other explanation why this threads hangs in this method for an hour, go on: "http-8580-Processor3" daemon prio=1 tid=0x7cdf11d0 nid=0x3269 runnable [7d7fe000..7d7ff8bc] at java.util.HashMap.get(HashMap.java:325) at org.apache.catalina.session.StandardSession.getAttribute(StandardSession.jav a:975) at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessi onFacade.java:109) ... > Sure, struts can't save you from this, but struts could give > you tools to > > right cleaner webapps. And it would be 20 lines of code. > > > Adding this to Struts would be: > > * Making applications *less* clean rather than more, because > they would be adding a layer of complexity around an existing > function provided by the platform APIs, without any > corresponding improvement in ease of use to compensate. > > * Creating needless runtime overhead on containers that do > not fail to handle get/set attribute safely. > > * Providing a false promise that using the utility methods > protects you from this flaw in the container. It can't > provide that guarantee. Ok, other suggestion, lets talk to the tomcat people, that they fix the bug, or at least add a party synchronized version of add/get/remove attribute. Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
