芯机智

 找回密码
 立即注册

扫一扫,访问微社区

搜索
热搜: 活动 交友 discuz
查看: 185|回复: 0

多线程使用unixODBC时,必须的配置(threadintg)

[复制链接]

534

主题

624

帖子

6282

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
6282
发表于 2018-6-22 09:28:20 | 显示全部楼层 |阅读模式
转: https://blog.csdn.net/mydriverc2/article/details/50497355
unixODBC是linux在平台上实现的ODBC驱动管理器(Driver Manager),当应用程序调用C函数SQLDriverConnect时,会依据参数以及ODBC的配置文件内容去调用具体的ODBC驱动程序动态库。比如MaxDB的驱动libsqlod.so和MySQL的MyODBC驱动libmyodbc3.so等。
在linux下,ODBC的配置文件有如下位置:
~/.odbc.ini
/etc/odbc.ini 或者 /usr/local/etc/odbc.ini
/etc/odbcinst.ini 或者 /usr/local/etc/odbcinst.ini
通常以rpm安装的unixODBC,是/etc下的配置文件起作用,如果是编译后安装的,是/usr/local/etc下的配置文件起作用;~/.odbc.ini是对该
用户的进程起作用,比如redhat系列的操作系统,以用户normal运行的进程,则会去找/home/normal/.odbc.ini。

配置文件中的大多数参数,在很多网站上都有说明,比如微软的网站、unixODBC的网站、MySQL的网站等等,这里就不多说了。本文只介绍一个unixODBC特有的,又与多线程有很大关系的参数----threading。从目前的经验来看,只要使用多线程来调用ODBC,用MySQL和MaxDB时是必须要设置的,通常设为0.
threading共有四个可取的值,从0到3.如果不设置此值的话,unixODBC会使用一个缺省值,比如我遇到的情况,缺省值是3。
在取1到3时,unixODBC会在调用ODBC函数时,加不同级别的锁,锁的粒度越粗,则各线程之间就越容易由于锁的互斥而进行等待。这种做法的初衷是考虑到具体的驱动可能不是线程安全的。
但是MaxDB的ODBC驱动,和MyODBC驱动,在各个线程不共享数据库连接的情况下,都是线程安全的。
并且从这一段时间的实践,如果不设置threading(即使用缺省值),一方面会导致速度很慢,另一方面会由于unixODBC加的锁与数据库端的锁共同作用而造成死锁。
比如有两个线程,分别称为A和B,它们都通过ODBC访问同一个数据库。
首先,A由于某个数据库操作,获得了数据库的某个锁,不妨称为DBLock;
然后,B调用某个ODBC函数,由unixODBC依据threading的值,通过pthread_mutex_lock获得一个锁,不妨称为UNLock;
之后,B恰巧由于某个操作,请求A获得的DBLock,此时在数据库一端就被锁住了,等待DBLock的释放,则B一直等待数据库的回应;
之后,A又要调用某个ODBC函数,而恰巧又要请求B已经获得的UNLock,这样,线程A就阻塞了,等待UNLock的释放。
也就是说,A在等B,B又在等A,客户端的锁与服务器端的锁共同作用,造成死锁。线程并未报错或者退出,但也不干活。
以目前的经验,在linux上使用ODBC连接MaxDB和MySQL,要在odbcinst.ini中加一句:
threading = 0

至于它的具体含义,我在网上查了挺久都没看到对它的详细解释,有点印象,以前好像在哪里见过的,但现在怎么也找不到了。最后在unixODBC的网站上发现这样一段话:
Since 1.6 if the driver manager was built with thread support you may add another entry to each driver entry. For example

[PostgreSQL]
Description = PostgreSQL driver for Linux & Win32
Driver = /usr/local/lib/libodbcpsql.so
Setup = /usr/local/lib/libodbcpsqlS.so
Threading = 2

This entry alters the default thread serialization level. More details can be found in the file DriverManager/__handles.c in
the source tree.

看unixODBC相关源码,首先是与threading取值相关的宏:
#if defined ( HAVE_LIBPTHREAD ) || defined ( HAVE_LIBTHREAD ) || defined ( HAVE_LIBPTH )
#define TS_LEVEL0 0 /* no implicit protection, only for */
/* dm internal structures */
#define TS_LEVEL1 1 /* protection on a statement level */
#define TS_LEVEL2 2 /* protection on a connection level */
#define TS_LEVEL3 3 /* protection on a environment level */
#endif
共有四个值,表示在什么级别上加锁。在unixODBC有这样一个函数,几乎在调每个ODBC函数的时候,都会调这个函数:
void thread_protect( int type, void *handle )
{
DMHENV environment;
DMHDBC connection;
DMHSTMT statement;
DMHDESC descriptor;

switch( type )
{
case SQL_HANDLE_ENV:
mutex_entry( &mutex_env );
break;

case SQL_HANDLE_DBC:
connection = handle;
if ( connection -> protection_level == TS_LEVEL3 )
{
mutex_entry( &mutex_env );
}
else if ( connection -> protection_level == TS_LEVEL2 ||
connection -> protection_level == TS_LEVEL1 )
{
mutex_entry( &connection -> mutex );
}
break;
case SQL_HANDLE_STMT:
statement = handle;
if ( statement -> connection -> protection_level == TS_LEVEL3 )
{
mutex_entry( &mutex_env );
}
else if ( statement -> connection -> protection_level == TS_LEVEL2 )
{
mutex_entry( &statement -> connection -> mutex );
}
else if ( statement -> connection -> protection_level == TS_LEVEL1 )
{
mutex_entry( &statement -> mutex );
}
break;

case SQL_HANDLE_DESC:
descriptor = handle;
if ( descriptor -> connection -> protection_level == TS_LEVEL3 )
{
mutex_entry( &mutex_env );
}
if ( descriptor -> connection -> protection_level == TS_LEVEL2 )
{
mutex_entry( &descriptor -> connection -> mutex );
}
if ( descriptor -> connection -> protection_level == TS_LEVEL1 )
{
mutex_entry( &descriptor -> mutex );
}
break;
}
}
这样基本上就有些概念了。
结论是,使用unixODBC时,一定要在odbcinst.ini中设置threading,通常设为0,避免用它的缺省值(很可能是3)。

[@more@]
在终极的分析中,一切知识都是历史;在抽象的意义下,一切科学都是数学;在理性的基础上,所有的判断都是统计。——C.R. Rao
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|芯机智 ( 京ICP备18048803号 )

GMT+8, 2019-10-15 07:06 , Processed in 0.160665 second(s), 21 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表