The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,343 other followers

database connection – Looking for a generic way to pool TCusomConnection in Delphi – Stack Overflow

Posted by jpluimers on 2018/10/11

What is the proper way for pooling of TCustomConnection instances in Delphi, that allows to distinguish between instances that have effectively equal connection properties and the ones that are effectively unequal?

I’ve tried searching the RTL and VCL sources and didn’t find a generic way.

I could copy either of the specific ones I found (see list below) and adapt them to a more generic solution or adapt one of the answers in #16404051 to be for TCustomConnection, but I wonder if there is an existing solution for TCustomConnection in the first place.

Specific ones I found in Delphi XE8:

  • DBX: unit Data.DBXPool
  • FireDAC: unit FireDAC.Stan.Pool
  • IBX: unit IBX.IBConnectionBroker

Source [WayBackdatabase connection – Looking for a generic way to pool TCusomConnection in Delphi – Stack Overflow

Hopefully by now I’ve some implementation for this that works nicely.

If not, these might get me started too:

In the .NET world, I take these things for granted, and it looks like ADO already does it out of the box as well:


via: [WayBack] Is there a Delphi library that allows for pooling of TCustomConnection… – Jeroen Wiert Pluimers – Google+

2 Responses to “database connection – Looking for a generic way to pool TCusomConnection in Delphi – Stack Overflow”

  1. stijnsanders said

    See, this is something I don’t get. What’s with all the pooling of connections? I typically have a tightly goverened set of worker threads, and each thread is responsible for it’s DB-connection. No pooling. The job-interface needs to get the connection object from the worker-thread when a job starts though. (And there’s a bit catching stray unclosed transactions)

    • jpluimers said

      Connections take server resources too, so in a heavily multi-threaded situation where not all threads need active DB connections all the time, a pool can make a lot of sense.

      Similarly in a situation where threads are being created/destroyed often, you do not want to create/destroy database connections each time as that usually takes a relatively long time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: