> 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.
Well, it says that you are not allowed to change the vector by the collection methods, but you are allowed to do it by the methods of the iterator. The checkTime method uses the methods of the iterator, so it is save to do it. Nico Klasens
