> It is a possibility. top output would help. Also, you could try the > following code: > <cftransaction> > > <!--- Fake query ---> > <cfquery datasource="test"> > SELECT 1; > </cfquery> > > <!--- Introduce 10 seconds pauze ---> > <cflock name="wait" timeout="12" type="readonly"> > <cflock name="wait" timeout="10" type="exclusive" throwontimeout="no"> > </cflock > </cflock> > > <!--- Fake query ---> > <cfquery datasource="test"> > SELECT 1; > </cfquery> > > </cftransaction> > > This will hold on to a connection for 10 seconds. In the mean time, run > a simple "SELECT 1" in another template and see if that comes back > before the connection is released. > > > > Can anyone say for sure that this problem would be solvd if we bought the > > Enterprise edition which has, I beleive, a native postgres driver? > > Are you sure it has one? Testing MX & JDBC might be a better idea. > > Jochem > The top output only shows one postgres connection as not being idle.
The fake queries separated by a time delay showed interesting results: while that was executing, I could perform CF operations from another screen. This tends to point to CF rather than the ODBC driver, no? CF makes the connection to the database, executes a query, gets the result, then knows that it has to wait around, so looks about for other queries to do, and does them. Whereas, with the long query, it issues the query and then just waits for the answer, not doing anything else until it gets one or times out. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
