none
请教一下多线程与数据库访问的知识 RRS feed

  • 问题

  • 最近关于多线程使用和数据库访问有一点疑问

    1.oledb方式与sqlclient方式的优劣

    ado.net方式 访问sqlserver数据库时,用oledb方式可以访问,用sqlclient方式也可以访问。

    请问相比较,使用sqlclient方式访问有什么优势呢?执行效率高一些?

    毕竟oledb方式可以访问很多数据库,只需要配置不同的数据连接字符串。对于数据库端类型常会变动的来说,用oledb方式很容易匹配其他类型的数据库啊,比如oracle。

    2.访问远程数据库,一般要用多线程吗?

    我是这样感觉的,有些时候,访问远程数据库,毕竟不像本地文件型数据库,存在一些不确定因素,比如网络断掉了,或数据库服务停掉了。

    做桌面应用程序时,用单线程的话,正常情况下当然没问题,界面停个1秒就恢复了。如果连不上数据库,界面就得卡死很久了。

    所以我想问一下,平时大家做东西时,访问远程数据库时,一般使用单线程访问,还是用多线程访问?

    3.Thread开启的线程,如何短时间内停止掉它

    基于第二条问题,我用多线程去访问数据库。如果出现连接不上时,我想让用户可以取消连接,而不用等待一直尝试继续连接。

    我用了Thread.Start()新开了个线程去访问数据库,但是连接过程中,我尝试用Thread.Abort()去终止这个线程,但是并不能很短时间内就停止这个线程,需要等上个7,8秒。

    请问如何才能够短时间内停止这个连接。

    我看QQ登陆时,虽然光登陆就要半天,但中途取消登陆时,一点取消就停掉了啊。虽然人家不是连接数据库卡住。

    2013年8月25日 3:02

答案

  • 1)既然微软为SQL单独配置了SQL类专门链接该类型的数据库,明显SQL比通用的OleDB通用性能好得多。建议用SQL,Oracle的下载针对的Oracle类库(需要上Oracle网)。至于说根据不同类型数据库,这个可以用工厂模式等解决。

    2)一般单线程,根据情况吧。如果单线程你可以设定SqlConnection的ConnectionTimeOut属性。超时时间。

    3)可以把Thread的IsBackGroundWorker设置为后台线程,这样你可以直接关闭主窗体,该线程自动被关闭。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    2013年8月25日 5:56
    版主
  • 1、上面回答了一部分,我再补充下你提到的数据库匹配的问题,一是,用 oledb 访问 oracle 时,你是需要安装 oracle client 组件的;二是,ado.net 的模型允许使用设计模式中的工厂模式和抽象工厂模式来创建具体的 DbConnection,也就是说,可以通过配置指定 Provider 来在运行时生成 DbConnection 的不同派生类。具体内容请参看:DbConnectionFactory。

    2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。

    3、ADO.NET 没有尝试继续连接的机制,在你设定的 Timeout 后如果未能建立连接,它就会抛出异常。Thread.Abort 并不总能理解停止线程(这取决于线程体包裹的代码),TerminateProcess 才能达到此目的。你观察到的 QQ 的现象,并不足以说明问题,我假设一次 DNS 查询需要 500 毫秒,建立连接需要 7 秒,发送完成需要 10 秒,收到第一个字节需要 20 秒,那么在这四个步骤的间隔中,你都可以立即终止(但是不是使用 Thread.Abort 机制,这是不行的。),但是在每个步骤中,却是没有办法立即终止的,你观察到的现象只是 QQ 将前一个登录的流程设置为废弃,实际上它仍然在后台运行,只是不在处理其结果。如果使用特殊的方式,比如重叠端口和完成端口时,可以在回调的时候去取消(只有触发回调时才占用线程,之前的操作都不占用线程),也可以在其它线程中去关闭已绑定 SOCKET (OS自己会花一定时间来慢慢的 CLOSE 该 SOCKET),从而来优化应用层。

    ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    2013年8月26日 1:58

全部回复

  • 1)既然微软为SQL单独配置了SQL类专门链接该类型的数据库,明显SQL比通用的OleDB通用性能好得多。建议用SQL,Oracle的下载针对的Oracle类库(需要上Oracle网)。至于说根据不同类型数据库,这个可以用工厂模式等解决。

    2)一般单线程,根据情况吧。如果单线程你可以设定SqlConnection的ConnectionTimeOut属性。超时时间。

    3)可以把Thread的IsBackGroundWorker设置为后台线程,这样你可以直接关闭主窗体,该线程自动被关闭。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    2013年8月25日 5:56
    版主
  • 1、上面回答了一部分,我再补充下你提到的数据库匹配的问题,一是,用 oledb 访问 oracle 时,你是需要安装 oracle client 组件的;二是,ado.net 的模型允许使用设计模式中的工厂模式和抽象工厂模式来创建具体的 DbConnection,也就是说,可以通过配置指定 Provider 来在运行时生成 DbConnection 的不同派生类。具体内容请参看:DbConnectionFactory。

    2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。

    3、ADO.NET 没有尝试继续连接的机制,在你设定的 Timeout 后如果未能建立连接,它就会抛出异常。Thread.Abort 并不总能理解停止线程(这取决于线程体包裹的代码),TerminateProcess 才能达到此目的。你观察到的 QQ 的现象,并不足以说明问题,我假设一次 DNS 查询需要 500 毫秒,建立连接需要 7 秒,发送完成需要 10 秒,收到第一个字节需要 20 秒,那么在这四个步骤的间隔中,你都可以立即终止(但是不是使用 Thread.Abort 机制,这是不行的。),但是在每个步骤中,却是没有办法立即终止的,你观察到的现象只是 QQ 将前一个登录的流程设置为废弃,实际上它仍然在后台运行,只是不在处理其结果。如果使用特殊的方式,比如重叠端口和完成端口时,可以在回调的时候去取消(只有触发回调时才占用线程,之前的操作都不占用线程),也可以在其它线程中去关闭已绑定 SOCKET (OS自己会花一定时间来慢慢的 CLOSE 该 SOCKET),从而来优化应用层。

    ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    2013年8月26日 1:58
  • 1)既然微软为SQL单独配置了SQL类专门链接该类型的数据库,明显SQL比通用的OleDB通用性能好得多。建议用SQL,Oracle的下载针对的Oracle类库(需要上Oracle网)。至于说根据不同类型数据库,这个可以用工厂模式等解决。

    2)一般单线程,根据情况吧。如果单线程你可以设定SqlConnection的ConnectionTimeOut属性。超时时间。

    3)可以把Thread的IsBackGroundWorker设置为后台线程,这样你可以直接关闭主窗体,该线程自动被关闭。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    thanks

    明显SQL比通用的OleDB通用性能好得多。这句话我没看看得特明白,应该是说sqlclient的连接比oledb的性能要好很多吧。

    那么同理,连接oracle的话,用odp.net或者system.data.oracleclient连接,也应该效率高一些吧。

    最近碰到一个问题,想追问一下

    最近要连别人的用户oracle数据库,是两家不同厂商提供的不同服务。其中一个db A我明确知道是用的usasccii7编码,另一个db b的字符集不清楚,db a跟db b是需要互相访问的。

    现在碰到这么个情况,我用odp.net连接,读取db a中的数据,由于字符集的问题,读取出来的中文都是乱码。写进去的中文,在pl/sqldev也显示为乱码。

    我用ms的oledb驱动去访问db a中的数据,中文正常,写入也正常。

    但是db a中,我用odp.net和system.data.oracleclient访问是正常的,可以正常显示中文,这两个驱动读取时,排序有所不同。

    用ms的oledb驱动去读取,中文却显示成了乱码了。看网上文章一般好像都说处理oracle字符集问题时,oledb访问无路什么字符集都会是正常中文,不会是乱码啊。

    请问,db a中这个,是不是本身存储的字符就不是正常存储的?

    2013年8月26日 16:27
  • 1、上面回答了一部分,我再补充下你提到的数据库匹配的问题,一是,用 oledb 访问 oracle 时,你是需要安装 oracle client 组件的;二是,ado.net 的模型允许使用设计模式中的工厂模式和抽象工厂模式来创建具体的 DbConnection,也就是说,可以通过配置指定 Provider 来在运行时生成 DbConnection 的不同派生类。具体内容请参看:DbConnectionFactory。

    2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。

    3、ADO.NET 没有尝试继续连接的机制,在你设定的 Timeout 后如果未能建立连接,它就会抛出异常。Thread.Abort 并不总能理解停止线程(这取决于线程体包裹的代码),TerminateProcess 才能达到此目的。你观察到的 QQ 的现象,并不足以说明问题,我假设一次 DNS 查询需要 500 毫秒,建立连接需要 7 秒,发送完成需要 10 秒,收到第一个字节需要 20 秒,那么在这四个步骤的间隔中,你都可以立即终止(但是不是使用 Thread.Abort 机制,这是不行的。),但是在每个步骤中,却是没有办法立即终止的,你观察到的现象只是 QQ 将前一个登录的流程设置为废弃,实际上它仍然在后台运行,只是不在处理其结果。如果使用特殊的方式,比如重叠端口和完成端口时,可以在回调的时候去取消(只有触发回调时才占用线程,之前的操作都不占用线程),也可以在其它线程中去关闭已绑定 SOCKET (OS自己会花一定时间来慢慢的 CLOSE 该 SOCKET),从而来优化应用层。

    ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    thanks

    1.dbconnectionfactory那个我需要自己去看一下工厂模式

    3.你说的qq连接的中间结束我明白大概意思了。

    连接池的问题不是很清楚,只知道ado.net默认就使用连接池,不需要自己再去搞那个。

    但是写程序时,怎么考虑这个呢?我现在写连接字符串时,字符串中除了连接必须的用户密码数据源外都没有写。没有写明最大连接数和最小连接数。

    2013年8月26日 16:40
  • 明显SQL比通用的OleDB通用性能好得多。这句话我没看看得特明白,应该是说sqlclient的连接比oledb的性能要好很多吧。

    那么同理,连接oracle的话,用odp.net或者system.data.oracleclient连接,也应该效率高一些吧。

    対,是的。

    第二個問題:

    既然你的db A是按照usaccii7編碼,當然用ms的OleDB讀取會産生亂碼。建議更改數據庫編碼或者改變你讀取字符的編碼。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    2013年8月27日 1:36
    版主
  • 1、上面回答了一部分,我再补充下你提到的数据库匹配的问题,一是,用 oledb 访问 oracle 时,你是需要安装 oracle client 组件的;二是,ado.net 的模型允许使用设计模式中的工厂模式和抽象工厂模式来创建具体的 DbConnection,也就是说,可以通过配置指定 Provider 来在运行时生成 DbConnection 的不同派生类。具体内容请参看:DbConnectionFactory。

    2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。

    3、ADO.NET 没有尝试继续连接的机制,在你设定的 Timeout 后如果未能建立连接,它就会抛出异常。Thread.Abort 并不总能理解停止线程(这取决于线程体包裹的代码),TerminateProcess 才能达到此目的。你观察到的 QQ 的现象,并不足以说明问题,我假设一次 DNS 查询需要 500 毫秒,建立连接需要 7 秒,发送完成需要 10 秒,收到第一个字节需要 20 秒,那么在这四个步骤的间隔中,你都可以立即终止(但是不是使用 Thread.Abort 机制,这是不行的。),但是在每个步骤中,却是没有办法立即终止的,你观察到的现象只是 QQ 将前一个登录的流程设置为废弃,实际上它仍然在后台运行,只是不在处理其结果。如果使用特殊的方式,比如重叠端口和完成端口时,可以在回调的时候去取消(只有触发回调时才占用线程,之前的操作都不占用线程),也可以在其它线程中去关闭已绑定 SOCKET (OS自己会花一定时间来慢慢的 CLOSE 该 SOCKET),从而来优化应用层。

    ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    thanks

    1.dbconnectionfactory那个我需要自己去看一下工厂模式

    3.你说的qq连接的中间结束我明白大概意思了。

    连接池的问题不是很清楚,只知道ado.net默认就使用连接池,不需要自己再去搞那个。

    但是写程序时,怎么考虑这个呢?我现在写连接字符串时,字符串中除了连接必须的用户密码数据源外都没有写。没有写明最大连接数和最小连接数。

    1、ODP.NET 字符集的问题,应该是个已知问题,你可以尝试更新到最新版本的 ODP.NET ,看看是否修复或提供了客户端的字符集设置选项(Oracle 的客户端组件可以设置字符集,但之前并没有可供 ODP.NET 调用的方式)。此问题,你也可以向 Oracle 反映;

    2、我提示连接池的问题,是表明,在启用连接池的情况下,ADO.NET 已经考虑到多线程的问题,在不同线程 Open/Close 连接是线程安全的。

    2013年8月27日 2:26
  • 明显SQL比通用的OleDB通用性能好得多。这句话我没看看得特明白,应该是说sqlclient的连接比oledb的性能要好很多吧。

    那么同理,连接oracle的话,用odp.net或者system.data.oracleclient连接,也应该效率高一些吧。

    対,是的。

    第二個問題:

    既然你的db A是按照usaccii7編碼,當然用ms的OleDB讀取會産生亂碼。建議更改數據庫編碼或者改變你讀取字符的編碼。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    你可能误会了我的问题。db a是usasccii7字符集,用ms oledb读取,是可以写入和读取正常的中文。odp.net不行。

    db b字符集我不清楚,用ms oledb读取才是乱码,odp.net与system.data.oracleclient访问正常。

    我现在是在同一个程序里用了两种方式,分别用于访问两个数据库。

    别人用vc写的程序,好像访问数据库时,没听他说有这个乱码问题。

    2013年8月27日 5:14
  • 1、ODP.NET 字符集的问题,应该是个已知问题,你可以尝试更新到最新版本的 ODP.NET ,看看是否修复或提供了客户端的字符集设置选项(Oracle 的客户端组件可以设置字符集,但之前并没有可供 ODP.NET 调用的方式)。此问题,你也可以向 Oracle 反映;

    2、我提示连接池的问题,是表明,在启用连接池的情况下,ADO.NET 已经考虑到多线程的问题,在不同线程 Open/Close 连接是线程安全的。

    谢谢关于连接池的提示,明白了你的意思。
    2013年8月27日 5:22
  • 明显SQL比通用的OleDB通用性能好得多。这句话我没看看得特明白,应该是说sqlclient的连接比oledb的性能要好很多吧。

    那么同理,连接oracle的话,用odp.net或者system.data.oracleclient连接,也应该效率高一些吧。

    対,是的。

    第二個問題:

    既然你的db A是按照usaccii7編碼,當然用ms的OleDB讀取會産生亂碼。建議更改數據庫編碼或者改變你讀取字符的編碼。


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats


    Found any spamming-senders? Please report at: Spam Report

    你可能误会了我的问题。db a是usasccii7字符集,用ms oledb读取,是可以写入和读取正常的中文。odp.net不行。

    db b字符集我不清楚,用ms oledb读取才是乱码,odp.net与system.data.oracleclient访问正常。

    我现在是在同一个程序里用了两种方式,分别用于访问两个数据库。

    别人用vc写的程序,好像访问数据库时,没听他说有这个乱码问题。


    VC 读取的时候客户端不会自动转码,程序可以根据实际的编码来将 char 数组转码成多字节或UNICODE。而 C# 中,string 统一是UNICODE 的,所以会有自动转码,如果可以的话,你可以按照 byte 数组读取该字段的值,然后再用 Encode 转换成 string 对象。
    2013年8月27日 5:25
  • VC 读取的时候客户端不会自动转码,程序可以根据实际的编码来将 char 数组转码成多字节或UNICODE。而 C# 中,string 统一是UNICODE 的,所以会有自动转码,如果可以的话,你可以按照 byte 数组读取该字段的值,然后再用 Encode 转换成 string 对象。

    你是说这么操作吗?

    遇到字符串就字段,就都当二进制数据,用byte[]读取过来,自己按其他编码方式,重新编码成字符串。

    thanks,我之后试试,暂时离开了那两个数据的实地环境了,没法马上试。

    如果这个方法可以的话,那基本上以后解决各种数据库字符集导致中文乱码的问题,都可以用它解决了,而不用去尝试各种不同的数据库驱动了。



    2013年8月27日 6:11
  • VC 读取的时候客户端不会自动转码,程序可以根据实际的编码来将 char 数组转码成多字节或UNICODE。而 C# 中,string 统一是UNICODE 的,所以会有自动转码,如果可以的话,你可以按照 byte 数组读取该字段的值,然后再用 Encode 转换成 string 对象。

    你是说这么操作吗?

    遇到字符串就字段,就都当二进制数据,用byte[]读取过来,自己按其他编码方式,重新编码成字符串。

    thanks,我之后试试,暂时离开了那两个数据的实地环境了,没法马上试。

    如果这个方法可以的话,那基本上以后解决各种数据库字符集导致中文乱码的问题,都可以用它解决了,而不用去尝试各种不同的数据库驱动了。




    是这样的。但是,关键就是数据库标记为char(nchar,nvarchar,varchar)的字段是否可按 byte 读取,或可由 sql 语句先转换成 blob 类型。
    2013年8月27日 6:21
  • 2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。


    我对这个现象,不太明确算不算耗时操作。UI需不需要多线程。

    正常情况下,不耗时间,单线程即可。

    异常情况,比如网络断了或连不上数据库,这个就是耗时操作了。
    工作环境中,一般是正常情况,但是也会出现异常情况。所以我不太知道应该按正常情况还是异常情况考虑了。

    不过目前我用了多线程,使用多线程,在正常情况和异常情况下都可以提供满意的用户体验。

    2013年8月27日 8:34
  • 2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。


    我对这个现象,不太明确算不算耗时操作。UI需不需要多线程。

    正常情况下,不耗时间,单线程即可。

    异常情况,比如网络断了或连不上数据库,这个就是耗时操作了。
    工作环境中,一般是正常情况,但是也会出现异常情况。所以我不太知道应该按正常情况还是异常情况考虑了。

    不过目前我用了多线程,使用多线程,在正常情况和异常情况下都可以提供满意的用户体验。

    UI 肯定是单线程的,而是你需要把非UI的操作放到非UI线程中去执行。通常涉及到 IO 操作的都会放置在非 UI 线程中去执行,比如连接网络,能连接上,并不表示就一定快,比如网络带宽限制、网络丢包较多,网络延迟较高时,或者 DNS 查询慢时,或服务器较繁忙,一次网络连接可能需要好几秒的时间,虽然它最终是连接上了。

    所以,不是因为连不上或网断了叫着“耗时操作”,而是你调用的方法的返回时间不确定,那么这些方法都应该放置在非UI线程中去执行。

    2013年8月27日 9:34
  • 2、对于需要处理耗时操作的 UI 程序而言,都需要使用多线程来提供用户体验。你这里是需要的,你可以将 Open 放置在后台线程中运行,然后通过事件来感知连接打开。


    我对这个现象,不太明确算不算耗时操作。UI需不需要多线程。

    正常情况下,不耗时间,单线程即可。

    异常情况,比如网络断了或连不上数据库,这个就是耗时操作了。
    工作环境中,一般是正常情况,但是也会出现异常情况。所以我不太知道应该按正常情况还是异常情况考虑了。

    不过目前我用了多线程,使用多线程,在正常情况和异常情况下都可以提供满意的用户体验。

    UI 肯定是单线程的,而是你需要把非UI的操作放到非UI线程中去执行。通常涉及到 IO 操作的都会放置在非 UI 线程中去执行,比如连接网络,能连接上,并不表示就一定快,比如网络带宽限制、网络丢包较多,网络延迟较高时,或者 DNS 查询慢时,或服务器较繁忙,一次网络连接可能需要好几秒的时间,虽然它最终是连接上了。

    所以,不是因为连不上或网断了叫着“耗时操作”,而是你调用的方法的返回时间不确定,那么这些方法都应该放置在非UI线程中去执行。


    谢谢
    2013年8月27日 12:14

  • ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    你好,关于连接池的问题,我还有一个疑问想请教下

    如果有连接池的话,客户端与数据库之间的连接是保持着的。连接池是不是会影响到数据库的并发?

    假如数据库并发数是15,那么是不是至多15个客户端同时开着,即便不是都在读取数据库,由于连接池保持连接,是不是也会占满数据库的并发连接数,导致新的客户端无法连接上数据库?

    连接池会影响到数据库的并发吗?

    2013年8月29日 1:06

  • ADO.NET 默认使用连接池机制,在编写程序时请务必考虑到这一点。

    你好,关于连接池的问题,我还有一个疑问想请教下

    如果有连接池的话,客户端与数据库之间的连接是保持着的。连接池是不是会影响到数据库的并发?

    假如数据库并发数是15,那么是不是至多15个客户端同时开着,即便不是都在读取数据库,由于连接池保持连接,是不是也会占满数据库的并发连接数,导致新的客户端无法连接上数据库?

    连接池会影响到数据库的并发吗?


    不影响并发连接数。
    2013年8月29日 1:18
  • 连接池会影响到数据库的并发吗?


    不影响并发连接数。

    这么说就算连接池中会保持连接,也不占用数据库的并发数,是吧。

    谢谢你

    2013年8月29日 3:04
  • 连接池会影响到数据库的并发吗?


    不影响并发连接数。

    这么说就算连接池中会保持连接,也不占用数据库的并发数,是吧。

    谢谢你

    对不起,我解释错了,我开始以为是sql server的许可数,统一下概念:最大并发连接数指的是“服务器属性”对话框中“连接”选项卡中的“最大并发连接数”。那么,该数和你的客户端连接池的连接数是一致的。你可以通过下面的命令来查询连接服务器的连接数:select count(*)from master..sysprocesses where hostname<>'' and dbid=db_id('northwind')。

    2013年8月29日 5:17
  • 对不起,我解释错了,我开始以为是sql server的许可数,统一下概念:最大并发连接数指的是“服务器属性”对话框中“连接”选项卡中的“最大并发连接数”。那么,该数和你的客户端连接池的连接数是一致的。你可以通过下面的命令来查询连接服务器的连接数:select count(*)from master..sysprocesses where hostname<>'' and dbid=db_id('northwind')。

    我是这么猜想,是不是客户端连接池会影响并发?

    比如服务器端最大并发连接数为10.每个客户端连接池保持2个连接。

    那么就没有办法超过5个客户端使用了吧?即使有些客户端并不访问数据库,但是连接池保持了连接

    2013年8月30日 15:53