Check the bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=36541
And yes, the HashMap explicitely prohibits the way it's been used by tomcat 5 StandardSession in it's javadoc. > -----Ursprüngliche Nachricht----- > Von: Wade Chandler [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 7. September 2005 21:11 > An: Tomcat Users List > Betreff: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() > > --- Remy Maucherat <[EMAIL PROTECTED]> wrote: > > > On 9/7/05, GB Developer > > <[EMAIL PROTECTED]> wrote: > > > coming late to the party with: > > > > > > > > > http://blogs.opensymphony.com/plightbo/archives/000175.html > > > > I had read your blog when you originally posted it, and > thought it was > > the most interesting blog I had read in months. IMO, given > the average > > size of the array in a typical hashmap (very small), they > should have > > added a robstness check (typically, e != e.next). > > > > -- > > xxxxxxxxxxxxxxxxxxxxxxxxx > > Rémy Maucherat > > Developer & Consultant > > JBoss Group (Europe) SàRL > > xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > Nothing shocking about HashMap. It becomes very hard to rely > on complex Objects if they are not being synchronized when > modified especially something like this....multiple lines of > code not being synchronized.... Any map which is being put > from multiple threads should be synchronized and anything in > an "inconsistant" state is a bad idea period. The hashtable > shouldn't be resizing anything when simply calling get..and > per the code it doesn't. A put must be called for a resize > to take place no if and or but about it, so it's not just a > getAttribute call or even 50 million of them alone going to > cause HashMap to lock, but rather the Object being in an > intermediate step when get is called. If you can use a > synchronized HashMap and the problem not occur then the > problem certainly comes from modifying the map and reading > from different threads at the same time which makes sense > when looking at the code and the javadoc statement(Directly > from the javadocs): > > Note that this implementation is not synchronized. If > multiple threads access this map concurrently, and at least > one of the threads modifies the map structurally, it must be > synchronized externally. (A structural modification is any > operation that adds or deletes one or more mappings; merely > changing the value associated with a key that an instance > already contains is not a structural modification.) This is > typically accomplished by synchronizing on some object that > naturally encapsulates the map. If no such object exists, the > map should be "wrapped" using the Collections.synchronizedMap > method. This is best done at creation time, to prevent > accidental unsynchronized access to the map: > > Map m = Collections.synchronizedMap(new HashMap(...)); > > Should be enough to explain the issue and why synchronization > should be used. I haven't looked at the Tomcat code, but why > would a Session not use synchronized maps? In my opinion > it's not a bug in HashMap as it's up front about it not being > synchronized. To fix the original posters current situation > they should be able to synchronize on an object when > accessing the session...you'll just have to track down all of > your calls which are setting and getting attributes and > synchronize the code. > > My 2 cents > > Wade > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
