[unixODBC-dev] thread strategies

Nick Gorham nick.gorham at easysoft.com
Wed Jun 29 15:52:21 BST 2005

Marek Kustka wrote:

> Hi,
> we have a web-based application which uses Firebird SQL server. Our 
> multithreaded back end
> server accesses it through UnixODBC and Easysoft's IB/FB driver. We 
> seem to have a problem
> when multiple simultaneous requests come up: Processing speed drops 
> down dramatically.
> I have setup some profiling points and found out that any arbitrary 
> ODBC call (such as
> SQLNumResulCols, SQLDescribeCol, SQLBindCol, SQLExecute) can take 
> 100-1000x longer
> time to process. Sorrounding ODBC calls from a given thread are 
> typically regularly fast.
> Probability of slow ones raises with increasing load from our app.
> My feeling is that it could be caused by some kind of synchronization, 
> because we are not able
> to load cpu(s) enough. I have scanned UnixODBC sources and noticed 
> comments about various
> thread strategies in __handles.c file.
> I want to ask if EasySoft's IB/FB driver handles some of these 
> synchronizations, so I could
> SAFELY lower the default level of 3 and test the effect. I can only 
> test it on our production database.
> We do use our own connection pool that handles a list of open 
> connections - this code is synchronized.
> Thanks to ODBC library we use, every our connection has different 
> environment handle.
> So we basically create, employ and drop statement objects in our 
> functions. We do not synchronize
> statement level ODBC calls at all.

As long as the version of the firebird interface lib you are using is 
thread safe, and you are using the current version of our driver  (there 
is a specific firebird version now) the you can leave the threading to 
the driver and remove the protection in the driver manager.

In older version of the interbase driver we had to protect the GDB lib 
as the Borland 6.5 version wasn't thread safe.

Nick Gorham
Easysoft Limited

More information about the unixODBC-dev mailing list