[unixODBC-support] Connection pooling: Use unixODBC built-in or roll my own?

Nick Gorham nick at lurcher.org
Fri Dec 18 15:32:54 GMT 2015

On 18/12/15 15:18, Mark Michelson wrote:
> Hi folks,
> Our project makes use of the unixODBC C API. We currently have a 
> poorly-implemented version of connection pooling within our 
> application, and we want to make improvements.
> Ideally, we would switch to a model where our application has no 
> knowledge of connection pooling whatsoever and rely on unixODBC to 
> take care of it under the hood. However, documentation on the matter 
> is pretty scarce. The only official document I found refers to a 
> version of unixODBC released in 2001 and claims that connection 
> pooling "[is] still in development" [1] . The only other things I 
> found were discussions about whether the use of connection pooling 
> would be a good fit for the type of application being used. In our 
> case, connection pooling is definitely something useful.
> I have a few questions about this: First, is the claim of the feature 
> still being in development true today? Second, does anyone have any 
> first-hand knowledge, good or bad, about using unixODBC connection 
> pooling?
> I've had a look at the source code of unixODBC, and from an "on-paper" 
> point of view, it looks like a simple solution that we could rely on. 
> However, when it comes to making fundamental changes like this to our 
> code, I'd like to have more confidence that we're making the correct 
> move.
> Thank you,
> Mark Michelson


Well, to the best of my knowledge, pooling is in the driver manager and 
works as described (copy of the way MS pooling was done). There have 
been a few fixes mostly relating to making sure its thread safe. I don't 
know of any outstanding problems with it at the moment. If there were , 
they would get fixed. Thats mainly how it goes, AFAIK, it works 
perfectly well unless someone else knows otherwise. i can't at the end 
of the day make your choices for you, but it sounds like you are already 
using unixODBC as part of your product, so it may not be that big a 
jump. And you have looked at the code, it should be as easy to fix the 
problem in unixOBC if you find one than your own code, and that way the 
rest of the user base gets the benefit as well.


More information about the unixODBC-support mailing list