Our query is returning in 20 milliseconds. So that is not the problem. Well the problem is still there in the newest MultiPool. The nowTime variable in the checkTime method should be inside the synchronized block. We think, we created a situation where the thread was waiting for a lock for longer than 120 sec. We are testing now if this is the solution.
Nico Klasens -----Original Message----- From: Kees Jongenburger [mailto:kees.jongenburger@;omroep.nl] Sent: Thursday, November 14, 2002 7:12 PM To: [EMAIL PROTECTED] Subject: Re: deadlock on JDBCProbe and MMobjectBuilder On Wednesday 13 November 2002 09:45 am, [EMAIL PROTECTED] wrote: > Hello mmbase developers, > > Our configuration: Weblogic 6.1 sp3 jdk1.3.1_06, solaris 2.8 (solaris 8), > Oracle 8.1.7 release 3 > > We have a publisher which changes the context (owner) state of nodes and > relations. The publisher is a new thread which wakes up every 60 seconds. > The database has indexes on the columns m_number, snumber and dnumber. We > have also an index on the owner column of the tables which we use in this > publisher. > > We think we don't need the checkTime method, but does somebody know why we > need this one? > We assume that this method is used to close "unclosed" connections, yes or long running queries (120 sec) > probably due to missing close statements in the code you could enable debuging for the MultiPool so that you know wat happens > And does somebody know a solution for our issue? There have been multiple issues/ bugfixes on MultiPool lately (a bugfix creating a new bug etc). You might not have this problem is you use a recent MultiPool.java the quick fix might be to "disable" checkTime by adding <property name="probetime">99999999</property> to jdbc.xml probetime (in seconds)
