the MTHCM has two shutdown attributes, one for the connection manager and one for the ReferenceQueueThread. If I am not mistaken, these attributes should be declared 'volatile' since they are used from different threads?
Agreed. Should be volatile.
The ReferenceQueueThread wakes up every second just to check the shutdown status. If the attribute is declared volatile and RQT.shutdown() modified to interrupt the thread, would that work without polling?
Yes, I think you're right. Removing the polling is the way to go.
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?
MTHCM.shutdownAll() synchronizes on the map for all the weak references. I assume this to be an optimization rather than a requirement to prevent deadlocks. Is that correct?
It prevents deadlocks and makes sure that no connections are allocated while things are being shutdown. It also allows for the ReferenceQueueThread to be restarted if/when new MTHCH instances are created. 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. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
