[Oledb-dev] Connection Pooling

[postgresql at bryden.co.za]

Firstly, let me say that it was not my intention to offend you, and if I
had done so, please forgive me. On reflecting on my comments, I can
understand how it would have been offensive.

You are absolutely correct in saying that I had misunderstood your
question. I was left with the impression that you had not heard of or did
not understand connection pooling. Once again, I appologise for this.

I most certainly will make an effort to put together detailed
specifications for connection pooling in Ole DB and pass these on to you.
Unfortunately, I would most likely not be able to help with the coding of
this as my strengths lie in Database Development / Data Warehousing and
not C++.

Regards,
Craig

> postgresql at bryden.co.za wrote:
>
>>>Do you have any specs on what pooling should look
>>>like?
>>>
>>>
>>If you need to understand connection pooling, here is a link that
>> explains
>>connection pooling :http://www.webopedia.com/TERM/C/connection_pool.html
>>
>>
> I'll retort with a link of my own:
> http://m-w.com/cgi-bin/dictionary?va=spec
> And, just to make sure you don't miss out on the reference:
> http://m-w.com/cgi-bin/dictionary?book=Dictionary&va=specifications&x=0&y=0
>
> The thing most lacking from the link you sent me is the second word
> (first non-small word) in definition 2a of the second link. If *you* can
> deduct what startup parameters to use, when is it ok to reuse a
> connection, whether session parameters need to be reset between sessions
> etc. from the link you sent, I bow my head in humility before your
> superior reading comprehension skills.
>
>>With all due respect, if you are writing a DB driver and you don't
>>understand connection pooling, then I am a bit worried
>>
>>
> Ok, here's "economics of open source 101". You get an OLE DB driver. You
> have to pay for it with neither money nor respect.
>
> The actual program you get varies in quality. Some of it is real junk.
> Some of it is downright brilliant. Most are somewhere in between, as is
> the case with commercial and proprietary software.
>
> Where free software does diverge from proprietary software is when you
> take a program that is in between, and want to move it a little toward
> the former group. Then it is time to pay up.
>
> There are several possible forms of payment. One is actual money. Since
> you already sent me an email in private, and since I have already sent
> you a link explaining the various forms that you can get support, I will
> not elaborate more on this avenue here.
>
> A second form of support is to provide your own. You can certainly sit
> down and write your own connection pooling implementation for PgOleDb.
> You can even send the implementation here, and I promise that if it's
> good enough, I'll integrate it into the main PgOleDb, so that you don't
> have to fork the project just for this feature. If I felt in a nasty
> mood, for example, because someone hinted that I don't know something
> fairly basic merely because they misread a question/request I made, I
> would have referred you to an answer Alan Cox once gave regarding the
> Linux kernel. When asked why didn't Linux have a driver for some webcam,
> his replay was "because you didn't write one".
>
> The sort of form, however, that support does usually take place in free
> software projects is where you ask *nicely* the programmer for a
> feature, and if the programmer has the time, (s)he will do it for you.
> Not for money. Not, even, because we need the feature ourselves, but
> because we care enough about the program we created to want to make it
> perfect.
>
> However, please do bear in mind that when doing that, you do have to
> give an incentive, and maybe even do some of the work. Now, it's obvious
> that you have quicker access to the specifications (we have a linguist
> who specializes in the origins of the English language on the list, so I
> can leave it to him to give you the exact history, but let's just agree
> that the word has some relationship with the word "specifics") of what
> connection pooling should look like *in Ole Db*. I mean, if you don't
> have access to the specs, how do you know whether the same connection
> can be used simultaneously by two threads, whether you need to reset
> session variables after opening a new session, etc. If you wrote a
> program that uses such a feature and didn't have the docs on hand
> explaining the specifics, I'd be a bit worried.
>
> The request I made to you was no different than the request I made to
> the people who want PostGIS support - let me know what PgOleDb needs to
> provide, with specifics (a.k.a. - specifications, also named "specs").
>
>           Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting ltd.
> http://www.lingnu.com/
>
>