>> 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 implementations provided by the JRE) may choose to throw this exception if this behavior is detected. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future. The pools are Vectors and a vector has synchronized methods. The vactor itself is thread-safe. The vector will block when a method of the Vector claas is executing. The Vector is only locked when the iterator.next() is executing. Another solution could be to just discard the ConcurrentModificationException and stop cleaning long running queries and try the next time, But then failed connections may exist in the busypool. Nico Klasens
