62,046
社区成员
发帖
与我相关
我的任务
分享请问：老提示应用程序池满了，这个咋解决啊？
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached
访问人数一多一点就这样……问题是数据库read和数据库连接不用的时候我都设置了关闭close
请问这个咋解决啊？
访问人数一多一点就这样……问题是数据库read和数据库连接不用的时候我都设置了关闭close
请问这个咋解决啊？
...全文
请发表友善的回复…
发表回复
正怒月神 版主 2017-01-17
- 打赏
- 举报
但感觉不是所有地方都适合在finally里面写啊？在finally里面执行效率会不会低一些？我不懂请教下会不？
我现在的问题，主要是判断比如一条记录满足条件，如果如何则关闭数据库连接并弹出提示[/quote]
一般都会把db的增删改查操作，封装到一个 sqlhelper吧？
没有的话，网上随便找找就有一堆。使用finally根本就是一件司空见惯的事。
不要 动不动就扯效率这个问题。就目前的问题来看，真的毫无意义
带头大哥_ 2017-01-17
- 打赏
- 举报
那是你没释放连接，改用using（）包起来的就包起来，比如sqldatareader，sqlconnect这些需要释放的最好都包起来，或者你自己写try catch
程序猿老曾 2017-01-16
- 打赏
- 举报
没错，像sp1234大哥说的，尽量使用using{...}这种方式，就不需要这么纠结关不关闭了~~~~
qq_34859304 2017-01-13
- 打赏
- 举报
好的，感谢，我去检查下！
闭包客 2017-01-13
- 打赏
- 举报
一般这种情况，都是没有调用 close，有些代码没有封装起 open 和 close 的操作，就容易留下没有关闭的连接。
如果确定连接使用完都有调用 close，再检查有使用 DataReader 去做耗时的操作，因为使用 DataReader 是保持连接状态的。
最后才去调整应用的最大连接限制。
csdxjsj 2017-01-13
- 打赏
- 举报
http://www.cnblogs.com/awpatp/archive/2010/08/29/1812016.html
qq_34859304 2017-01-13
- 打赏
- 举报
但感觉不是所有地方都适合在finally里面写啊？在finally里面执行效率会不会低一些？我不懂请教下会不？
我现在的问题，主要是判断比如一条记录满足条件，如果如何则关闭数据库连接并弹出提示
吉普赛的歌 2017-01-13
- 打赏
- 举报
解铃还须系铃人， 谁干的找谁。
正怒月神 版主 2017-01-13
- 打赏
- 举报
我习惯在finally中写关闭事件。
sy401042879 2017-01-13
- 打赏
- 举报
上完厕所你不擦屁股，虽说你放在太阳底下也能风干，但也有天阴的时候。
用完记得close，养成良好习惯即可。
闭包客 2017-01-13
- 打赏
- 举报
嵌套了什么？
我知道你是多余地嵌套了。我回答了 lz 实际问题，我说过“关闭 DbConnection 就可以了，什么 DbReader、DbCommand 之类的都不需要关闭”。而你显然是在说无关的东西也要多余地去写“嵌套”。[/quote]
大多数情况下，using 都是比写 try finally 要好的。
但是好处并不是什么【标准化方法】、【结构化工程】这种虚无缥缈的概念。
它的好处，仅仅是【少写了几行】。
以专业开发人员为伍 2017-01-13
- 打赏
- 举报
手工调整连接池的数量，其实作用不大，通常是“暂时治愈自己的幼小的心灵”的一个缓兵之计，就好像小孩子摔倒了、他妈妈就会打那个地面，其实基本上都是荒唐地欺骗孩子自己的！
当你的程序遇到了经常爆出这个问题，在系统并发数量升高的时候，你设置多少都没有用，一定会撑爆内存、卡死 CPU 也还不够连接池使用！
原本连接池最大数量200足够30万人（网站的）并发使用了，你现在设置为2000也未必能支持30个人熟练地使用业务网站，为什么？自己想想这个道理就能明白，程序是自动化的，有 bug 就干净彻底地解决bug，才是正道。
另外，假设你在一些循环迭代、递归的程序中过分新建了数据连接，例如你遍历某个组织结构树的子节点时，每一层递归操作中不恰当地重新打开了数据库连接，那么你可能在只有1个用户使用时也会经常遇到“连接池满”的异常。因为程序有 bug，再你用户很小的“组织结构”测试数据时没发现，实际用户一旦用一个150个子部门的组织结构模型来测试可能就崩溃了。
总之这些都属于 bug。千万不要以改动连接池数量为方案。是在不得已，可以“玩玩儿”去设置一下。然后第二天还是设置回默认值。
默认值是千锤百炼的一个默认值。真正的问题几乎都是你自己的程序 bug 问题。不要去学某些 linux 下的程序员那样，写不了多少原创的代码，却把绝大部分精力用来讨论去修改人家开源代码的配置。
以专业开发人员为伍 2017-01-13
- 打赏
- 举报
嵌套了什么？
我知道你是多余地嵌套了。我回答了 lz 实际问题，我说过“关闭 DbConnection 就可以了，什么 DbReader、DbCommand 之类的都不需要关闭”。而你显然是在说无关的东西也要多余地去写“嵌套”。
以专业开发人员为伍 2017-01-13
- 打赏
- 举报
重点不是程序员要不要写 using，重点是要求程序员不要写 close 代码。
注意不要偷换概念。这里是结构化工程的重点。
fangj87 2017-01-13
- 打赏
- 举报
楼主问题解决了吗？ 我最近也是碰到这个问题了，搜寻网上的方法如下：
解决方法(*):WEB.config 里面:在数据库连接加 Max Pool Size = 512;server=local;uid=;pwd=;database=2004;Max Pool Size = 512;\">一劳永逸。
但是我们这个config文件中数据库连接字符串被加密了，不知道如何解密呢？请教论坛的大神们解答一下。
闭包客 2017-01-13
- 打赏
- 举报
using 的确是好的选择，但不是必须要这样做的。
第一，using 不能帮助健忘的程序员，只要程序员粗心，结果是一样的。
第二，using 还会造成程序块嵌套过多的问题。在同时使用多个非托管对象时，反而不如 try finally
吉普赛的歌 2017-01-13
- 打赏
- 举报
1. sp1234说的还是有用的， 必须写 using;
2. 必须加上连接池的参数， 最大512;
3. 数据库上加上作业来监控连接数, 有过多连接数时预警， 再看看是否一些需要优化的脚本。
闭包客 2017-01-13
- 打赏
- 举报
关闭 DbConnection 就可以了，什么 DbReader、DbCommand 之类的都不需要“关闭”。
关键是你要确认确实“关闭了”DbConnection。最基本的保证方式，就是“永远不写代码关闭DbConnection”，而是使用 using{ .... } 结构来自动关闭它。这可以保证无论是否抛出异常，都能在结构结束时确保关闭数据库逻辑连接。
少写手工代码，多用自动化结构化代码，才是保证代码正确的根本。[/quote]
using 不还是需要程序员去写么？
如果这个程序员忘记了，结果还是一样。
以专业开发人员为伍 2017-01-13
- 打赏
- 举报
另外，你说“数据库连接不用的时候我都设置了关闭close”这个也要看其实际耗费时间而定。
有些人的某些页面很低效率，比如说用时15秒钟，结果他在页面处理开始时创建并且打开了这个 DbConnection，然后一直到页面处理结束时才关闭它，中间许多方法都使用这个连接，这就是错误的做法。因为一个15秒钟的数据库连接对于高并发系统来说就是灾难，一个数据库逻辑连接应该尽量在几百毫秒之内就释放掉了（返还给连接池去共享给其它并发查询使用），而不能耗费15秒。如果一个页面处理真的要使用15秒钟，那么你的这个页面处理还是要在各处细节去“及时打开、及时关闭”数据库逻辑连接，而不应该去一直霸占连接。
反之，如果你的应用有一些嵌套、递归操作，你反而不需要反复申请数据库逻辑连接。因为你的操作不涉及什么“延迟”问题，此时正好应该把数据库逻辑连结对象作为参数，让不同方法共享！
所以不具体去分析问题，简单抄袭一些字眼儿，是发现不了或者解决不了多少实际问题的，走不远的。
闭包客 2017-01-13
- 打赏
- 举报
可以这么说。但我认为调用了 close 之后，reader 是没有办法 next 的。
加载更多回复（3）
