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