On Tuesday 17 December 2002 03:32 pm, [EMAIL PROTECTED] wrote: > Hello everyone, > > I am testing now the mmbase 1.6 rc3 for VPRO digitiaal and getting the > ConcurrentModificationException for almost every scan editor I use. The > scan editors create long running queries. After the errror the connections > and driver of informix are throwing wierd errors. > > Bug #3469 says that it fixed the issue, but that is not the case. > The source code of MultiPool version 1.20 is not threadsafe at all if you > ask me. > > Threads can just freely get a connection and put it back even when the > JDBCProbe > checks the connections with checktime. > > Scenario > thread 1 calls getFree and passes the semaphore.acquire() > thread JDBCProbe . calls checktime > > at this point the JDBCProbe is iterating over the busypool collection and > thread 1 can add a connection to the busy pool. isn't the semaphore locked by the JDBCProbe? free also cals the semarphore btw
>The semaphore is locked by the JDBCProbe, but should still be locked by thread 1. never lock the semaphore (it calls a wait) > > The scenario continues.. > thread JDBCprobe is still running checktime. > thread 1 executes the query > thread 1 calls putback and waits for the JDBCProbe at the statement > semaphore.release(); > > In this simple scenario (can happen always when JDBCProbe runs) > the ConcurrentModificationException can be thrown at 2 points in time. > when getFree adds a connection to the busypool or when putback removes a > connection. The "Whole" problem exists because we use an iterator over the pools and in the probe we need to modify the pools if we want to control them... IMHO we should only make a getConnection() wait "if and ony if" all the connections are used (this is currently the case). > > The system becomes instable when a connection is running longer then > 2 minutes and this exception is thrown. > > I think this is a big issue in 1.6rc3. > I will write a fix this afternoon to get my project back on track. fine :)
