Hi Mike, >> MTHCM.shutdownAll() might be a bit unsafe since it iterates >> over a WeakHashMap and does not handle ConcurrentModifcation- >> Exception: >> http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html > > Not sure. In what scenarios would this occur do you think? What > other thread would be modifying the map?
The garbage collector. The class comment for WeakHashMap is full of warnings like this one: Because the garbage collector may discard keys at any time, a WeakHashMap may behave as though an unknown thread is silently removing entries. In particular, even if you synchronize on a WeakHashMap instance and invoke none of its mutator methods, it is possible... In 1.4, they added some sections: Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. So they can not _guarantee_ that a CMX is thrown if the GC drops something from the map during the iteration, but they'll try to. > When we get around to refactoring/rewriting the MTHCM ideally it would > be best if the weak references, queues, etc could be separated from > the connection pool. This code ads a lot of complexity, requires a > thread, and when connections and managers are used correctly should > not even be necessary. At the moment I have no idea how exactly this > could be done, but I thought it should be considered. Yes, I've already been thinking about moving the reference tracking to an extra class. Some of my question had exactly that background. But there are more important things to be taken care of first, so I'll let this settle for a while. Except for the volatile/non-polling stuff. Maybe I'll come up with a patch for 3.1. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
