[unixODBC-dev] Pooling issues

[Jess Balint]

On Tue, Apr 07, 2009 at 10:06:41AM +0100, Nick Gorham wrote:
> Jess Balint wrote:
>
>> We were recently alerted to some issues and have some questions
>> regarding the unixODBC code.
>>
>> * SQLConnect.c:3355 has a comment: "TODO - alter the mutex level here"
>>  Would just a call to dbc_change_thread_support() suffice?
>> * In dbc_change_thread_support(), what is the inteded use of mutex_lists
>>  here? It looks to me it makes the lock "switching" atomic with respect
>>  to other concurrent calls to this function.
>> * dbc_change_thread_support() also doesn't seem to properly support
>>  "Threading" parameter level 0 (connection is still locked). Would a
>>  call to thread_protect be a better solution here?
>>
>> Thanks for any feedback.
>> Jess
>> _______________________________________________
>> unixODBC-dev mailing list
>> unixODBC-dev at mailman.unixodbc.org
>> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
>>  
>>
> Going back to this, can someone let me know of some code or a situation  
> that causes the reported problem to happen.

When search_for_pool() is called in SQLConnect, the env lock is held due
to the default TS_LEVEL3 on the hdbc. If the driver has configured a
more granular locking level, the value is applied to the connection
object, around line 3346. When SQLConnect() returns, it will (under
level 1 or 2) attempt to release the connection lock, or release no lock
(under level 0). However, since dbc_change_thread_support() was never
called, the env lock is still held.

> Is the driver in question thread safe?

Yes, in this case the driver is MySQL.

> Does anyone know of any thread unsafe drivers out there? As I would love  
> to pull all the code that tries to protect unsafe drivers is its never  
> being used.

It seems to be a useful feature, and not too difficult to fix for
pooling.

Jess