On Wednesday 18 December 2002 02:01 pm, [EMAIL PROTECTED] wrote: > >> That is just the problem. The JDBCProbe locks the semaphore in checkTime > >> to let other > >> threads wait for him to unlock the semaphore. This is required because > >> the JDBCProbe > >> needs full control over the busypool. The checkTime method iterates over > >> the busypool and will freak out if the connections in the busypool > >> change. > > > > why. what is actualy throwing the Concurrent modification Exception? > > int's it "just" the iterator that freaks out? > > the pools are thread safe.. (I think) > > The ConcurrentModificationException may be thrown by methods that have > detected concurrent modification of an object when such modification is > not permissible. > > For example, it is not generally permssible for one thread to modify a > Collection while another thread is iterating over it. In general, the > results of the iteration are undefined under these circumstances. > Some Iterator implementations (including those of all the collection from the Vector javadoc
* The Iterators returned by Vector's iterator and listIterator * methods are <em>fail-fast</em>: if the Vector is structurally modified * at any time after the Iterator is created, in any way except through the * Iterator's own remove or add methods, the Iterator will th * on a best-effort basis. * Therefore, it would be wrong to write a program that depended on this * exception for its correctness: <i>the fail-fast behavior of iterators * should be used only to detect bugs.</i> the way I read it means that even adding a new element to the vector within the iterator loop may fail. if you have code that solves the problem please post it and we wil look at it.
