At 09:35 26/2/01 -0500, Berin Loritsch wrote: >I have a feeling that we are dealing with a Race Condition on the AbstractPool.
quite Possible. >I think we should make all Pools ThreadSafe. This contract will make things >alot easier for people who are implementing pools in concurrent execution >environments (i.e. multithreaded). In cocoon, I will explicitly synchronize >the get() and set() methods--but this is a temporary stop-gap until we make >the Pool implementation thread-safe. All pools used in a multithreaded environment should use ThreadSafePool. DefaultPool is for use in single-threaded environments. >I do think there is room for multiple different types of pools: > >* Hard resource limiting (Absolutely no more than X components) >* Soft resource limiting (May have more than X, but extras are destroyed when returned) >* No resource limiting (As extras are needed, they are created and maintained) agreed ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
