Re: [Firebird-odbc-devel] connection pooling

[Helen B. <he...@ii...>]

At 11:54 PM 19/11/2010, Chris Scott wrote:

>Hi Alexander, thanks for checking that.  We are using version 1.03.00.96 of the firebird odbc driver.  Is there a chance that this older version did use connection pooling?  If I reboot our firebird 1.5 server and then run an infoview report several fb_inet_server processes appear on the firebird server.
> 
>On 19.11.2010 3:18, Chris Scott wrote: 
>We have a server running SAP Crystal Server XI.  We use the program called infoview (web portal) to run crystal reports.  This connects to the firebird 1.5 database using an ODBC connection.  

Old Firebird version, very old ODBC driver version...see comment below.

>My understanding is that the firebird ODBC driver uses connection pooling.  Is it possible to configure the min and max connections in this connection pool?

Any ODBC driver is one component in a heavily layered scenario that, broadly, provides an interface between your client application and a database.  To do this, it implements "translations" of Firebird's API function calls and structures (which are in C language) into structures that are defined by the ODBC standard.  This translation, again broadly, allows application layers, written in a variety of host languages, to pass requests to the database engine and receive responses that they can understand and work with. 

The driver cannot make the database engine do things that are not defined in the API.  The API is pitched at one connection per database and the transactions and requests within that single connection context. 

If there is an application in the layering structure that wants to pool connections, that application would be written to manage multiple client connections in such a way that client instances could request a connection and be allocated one from a pool of available connections.  An "available connection" would be one instance of the database driver connected to one database and flagged as "not currently in use". In your setup, it is the InfoView software that is providing that pool-management layer.  

The Infoview pooling mechanism (if it really exists) would be creating, for each connection in the pool, one instance of the ODBC driver (client) connected to one fb_inet_server process - that is the Classic model of the Firebird engine.  If the ODBC driver never receives a detach_database call from the Infoview layer then none of those fb_inet_server processes will end.  The Infoview pooling mechanism *will* have some limit to the number of fb_inet_server instances it has running, along with some kind of configuration (in Infoview) that allows your installation to be limited to some maximum number of connections (processes) so as not to overwhelm your server's resources.

If the Infoview support people have told you something different then perhaps you have not spoken to the right people. 

Having said all that, I note that you are using both a very old version of Firebird and a very old version of the ODBC driver, with the Classic server model.  I hope you are not running the Guardian (fbguard.exe) with Classic.  If you are, then you have what was a known source of "ghost processes" when Firebird Classic was introduced for Windows and the early versions of the installer did not prevent you from installing Guardian with Classic.  Do that reality check if you have not already done so.  Take the Guardian right out of the picture:  it should not be there!

Helen