DotNetFirebird.org DotNetFirebird
Using Firebird SQL in .NET.
Wednesday, February 16, 2005

Connection Pooling

Firebird ADO.NET provider supports connection pooling. By default, connection pooling is turned on. That means that when you call Close method on FbConnection instance the connection to the server is not closed but is returned to the pool.

Connection pooling is useful especially for Web applications. Each page request would otherwise need to open a new connection and that can be time expensive.

You can modify the behavior of connection pooling in the connection string by using these parameters:

Parameter  Default value Description
Pooling true Enables or disables connection pooling for this connection. If it is false, a new connection will always be opened.
MinPoolSize 0 The minimum connections that are always open in the pool
MaxPoolSize 100 The maximum connections that will be in the pool.
Connection Lifetime 0 How long should the connection remain in the pool (in seconds) after its creation. It is checked when the connection is returned to the pool. 0 means that the connection never expires.

Since version 1.7 of the Firebird ADO.NET Provider you can check the number of connections in the pool using FbConnection.GetPooledConnectionCount().

You can explicitly clear a pool using FbConnection.ClearPool() or all pools using FbConnection.ClearAllPools().

Things to remember:

  • The connection pools are created per connection string. If you modify the connection string a new connection (and a pool) will be created.
  • The connection is returned to the pool when calling Close() method of FbConnection.
  • When you use connection pooling it is better to open the connection as late as possible and close as soon as possible.

Comments:

hello,

i don't know if it's a bug but it may be usefull for other developer.

i'm using DotNetFirebird with a win2000/IIS 5 webserver. This webserver is located on the "orange (DMZ)" network of a linux/IPCop firewall.
My DB server is not firebird but Interbase open v6, located on the "green (local)" network.
The connection string for dotnet provider contain the IP address of this DB server, database name and username/password only.

On the IPCop machine i've configured a pinhole to allow DMZ webserver to connect to my DB server (TCP port 3050).

When i use this configuration, it take 10 seconds to connect to the DB.

After one day of verification of my code, i've added a 2nd pinhole from DMZ to DB server on port 137 (NetBios - NS). And now it take less than two seconds to connect to the database.

Well, may a bug of IIS, IPCop, Interbase or dotnet provider...

i wish it could help someone.
Blog comments are closed.



Previous

Archives