23,407
社区成员
发帖
与我相关
我的任务
分享求救大侠英语水平，帮小弟翻译下。网上翻译就算了
1：Change "max_statements" to 0 and try... I'm not sure it will work, but that's what worked for me. The difference is that I was using Firebird, and there was already a related issue.
2：That would likely get rid of the statement cache messages, but unless I misunderstand the feature, it would be "fixed" at the cost of totally disabling the prepared statement cache. I'd kinda like to retain the performance value gained from reusing statements. But thanks anyway!
3：I'm surprised that no other theories or options have come out... Is there really no way to deal with the cached statement warnings other than to completely disable prepared statement caching? If so, that reduces the value of c3p0 to connection pool only. I'd appreciate any other insights on the subject... Thanks.
4：Mark,
May the StatementCache be with you.
Regarding your deadlocks, they are interesting. The tasks that are failing to terminate are not the Statement cache tasks, but Connection close() tasks. Nevertheless, past deadlocks have occurred because of Statement close was happening simultaneous to Connection close(), and I'm suspicious that we are seeing more of the same here, since you are clearly churning though a lot of PreparedStatements. (You have a zillion pending statement close tasks, and three Connection close tasks that are failing.)
0.9.0 cleared up the most obvious bad interaction between Statement and Connection close(), but it occurs to me that the strategy does not yet guarantee that a PreparedStatement and Connection close cannot occur asynchronously and near simultaneously by happenstance, especially when Statements are being close()ed quite frequently. So, my job is to tighten that up. [Even though in theory it should be foreseen and handled cleanly, many drivers don't like Statements to be used simultaneous to Connection ops or after Connection close().]
Your job is this: 1) take moonlight's suggestion for just long enough to persuade yourself that the statement cache is implicated in the apparent deadlock, and write back to let me know the problem goes away when statement caching is turned off; 2) try making max_statements much, much larger, or set it to 0 and set c3p0.maxStatementsPerConnection in c3p0.properties to as many distinct PreparedStatements as your application ever uses. This will both improve the performance of your application (statement caching doesn't much help if you are always churning through the statements), and make the deadlock you are seeing, presuming it is an artifact of statement close simultaneous with connection close, much less likely. The only likely downside of a large max_statements is the potential memory footprint (see how it works for you), but there may be many upsides. Do give it a shot.
Good luck!
Steve (c3p0 guy)
5：That will not likely be workable for me, as I am not running just a single program (ie tomcat) that can afford a bunch of new overhead. My environment is a bunch of separate daemons and jobs that connect to the db to do separate work, and I can't allow these N processes to all gain a bunch of new overhead.
I guess I'll leave caching off for now (which isn't currently a performance issue) and hope that there will be a concrete fix for it before I absolutely need to turn caching back on.
Thanks!
Mark
6：I am seeing similar issues with MySQL 4.1 using the JDBC driver version 3.1.11. We did find a bug in MySQL JDBC driver souce code where statement close & connection close could run into a deadlock. Is there any kill mechanism in c3p0 for a hanging close() call? Do we interrupt the thread or something like that?
Thanks Steve for your notes on making statement close less likely to be used. I haven't tried it but I'm pretty sure I wouldn't be able to use this because I'm running a highly multi-threaded text indexing application that is somewhat sensitive to memory usage.
7：ramvem,
c3p0-0.9.1 will have a "maxAdministrativeTaskTime" parameter, which will call interrupt() on c3p0's helper threads when an administrative task [Connection acquisition or test, Connection or cached Statement destruction] is taking too long. "APPARENT DEADLOCK"s will also include stack traces of the deadlocking tasks if on a 1.5+ VM (which offers the Thread.getStackTrace() method). Though these APPARENT DEADLOCKS seem to be a lot less common in 0.9.0.x than they used to be, they still do occur for some users, and I'm hoping to get a much better handle on why...
c3p0-0.9.1-pre7 will be available within a few days with this functionality (and quite a few other changes). If you have the luxury of being able to test a gree prerelease, please do give it a good hard go.
smiles,
Steve
8：I'm actually running into the same issue using hibernate-3.2.1.ga, c3p0-0.9.1-pre6, mysql-connector-java-5.0.4 on mysql 5.0.27. The caveat is that it happens when I run it under ServiceMix. The issue thread can be found here: http://www.nabble.com/issues-with-deadl ... 12049.html
I wanted to try upgrading to c3p0-0.9.1-pre7 but the c3p0 site is currently down. If you have any suggestions for me to troubleshoot, please let me know. Thanks in advance.
-los
9：hi,
please try c3p0-0.9.1-pre11. i think most of these APPARENT DEADLOCK issues are now resolved, though of course you can prove me wrong...
if you have trouble reaching c3p0's website on mchange.com (we're having some network issues), please go to sourceforge.net and search for c3p0. sourceforge hosts the actual releases.
good luck!
steve
10：Hi,
I actually switched to pre11 and its still giving me "too many connections" issues. Can I send you my stacktrace directly via email? Thanks.
-los
11：I've got it working. Its actually an issue with Hibernate 3.2.1.ga. Not changing any of my code, when I switched back to 3.2.0.ga using c3p0pre11, everything worked out fine. So its either a bug with hibernate or c3p0 needs to update to reflect any 3.2.1 changes (I think its the former though).
-los
12：I've been on pre11 and 3.2.1 for a little while and having these problems, usually when reloading web apps from the tomcat manager. Just rolled back to 3.2.0 and haven't had any problems yet.
2：That would likely get rid of the statement cache messages, but unless I misunderstand the feature, it would be "fixed" at the cost of totally disabling the prepared statement cache. I'd kinda like to retain the performance value gained from reusing statements. But thanks anyway!
3：I'm surprised that no other theories or options have come out... Is there really no way to deal with the cached statement warnings other than to completely disable prepared statement caching? If so, that reduces the value of c3p0 to connection pool only. I'd appreciate any other insights on the subject... Thanks.
4：Mark,
May the StatementCache be with you.
Regarding your deadlocks, they are interesting. The tasks that are failing to terminate are not the Statement cache tasks, but Connection close() tasks. Nevertheless, past deadlocks have occurred because of Statement close was happening simultaneous to Connection close(), and I'm suspicious that we are seeing more of the same here, since you are clearly churning though a lot of PreparedStatements. (You have a zillion pending statement close tasks, and three Connection close tasks that are failing.)
0.9.0 cleared up the most obvious bad interaction between Statement and Connection close(), but it occurs to me that the strategy does not yet guarantee that a PreparedStatement and Connection close cannot occur asynchronously and near simultaneously by happenstance, especially when Statements are being close()ed quite frequently. So, my job is to tighten that up. [Even though in theory it should be foreseen and handled cleanly, many drivers don't like Statements to be used simultaneous to Connection ops or after Connection close().]
Your job is this: 1) take moonlight's suggestion for just long enough to persuade yourself that the statement cache is implicated in the apparent deadlock, and write back to let me know the problem goes away when statement caching is turned off; 2) try making max_statements much, much larger, or set it to 0 and set c3p0.maxStatementsPerConnection in c3p0.properties to as many distinct PreparedStatements as your application ever uses. This will both improve the performance of your application (statement caching doesn't much help if you are always churning through the statements), and make the deadlock you are seeing, presuming it is an artifact of statement close simultaneous with connection close, much less likely. The only likely downside of a large max_statements is the potential memory footprint (see how it works for you), but there may be many upsides. Do give it a shot.
Good luck!
Steve (c3p0 guy)
5：That will not likely be workable for me, as I am not running just a single program (ie tomcat) that can afford a bunch of new overhead. My environment is a bunch of separate daemons and jobs that connect to the db to do separate work, and I can't allow these N processes to all gain a bunch of new overhead.
I guess I'll leave caching off for now (which isn't currently a performance issue) and hope that there will be a concrete fix for it before I absolutely need to turn caching back on.
Thanks!
Mark
6：I am seeing similar issues with MySQL 4.1 using the JDBC driver version 3.1.11. We did find a bug in MySQL JDBC driver souce code where statement close & connection close could run into a deadlock. Is there any kill mechanism in c3p0 for a hanging close() call? Do we interrupt the thread or something like that?
Thanks Steve for your notes on making statement close less likely to be used. I haven't tried it but I'm pretty sure I wouldn't be able to use this because I'm running a highly multi-threaded text indexing application that is somewhat sensitive to memory usage.
7：ramvem,
c3p0-0.9.1 will have a "maxAdministrativeTaskTime" parameter, which will call interrupt() on c3p0's helper threads when an administrative task [Connection acquisition or test, Connection or cached Statement destruction] is taking too long. "APPARENT DEADLOCK"s will also include stack traces of the deadlocking tasks if on a 1.5+ VM (which offers the Thread.getStackTrace() method). Though these APPARENT DEADLOCKS seem to be a lot less common in 0.9.0.x than they used to be, they still do occur for some users, and I'm hoping to get a much better handle on why...
c3p0-0.9.1-pre7 will be available within a few days with this functionality (and quite a few other changes). If you have the luxury of being able to test a gree prerelease, please do give it a good hard go.
smiles,
Steve
8：I'm actually running into the same issue using hibernate-3.2.1.ga, c3p0-0.9.1-pre6, mysql-connector-java-5.0.4 on mysql 5.0.27. The caveat is that it happens when I run it under ServiceMix. The issue thread can be found here: http://www.nabble.com/issues-with-deadl ... 12049.html
I wanted to try upgrading to c3p0-0.9.1-pre7 but the c3p0 site is currently down. If you have any suggestions for me to troubleshoot, please let me know. Thanks in advance.
-los
9：hi,
please try c3p0-0.9.1-pre11. i think most of these APPARENT DEADLOCK issues are now resolved, though of course you can prove me wrong...
if you have trouble reaching c3p0's website on mchange.com (we're having some network issues), please go to sourceforge.net and search for c3p0. sourceforge hosts the actual releases.
good luck!
steve
10：Hi,
I actually switched to pre11 and its still giving me "too many connections" issues. Can I send you my stacktrace directly via email? Thanks.
-los
11：I've got it working. Its actually an issue with Hibernate 3.2.1.ga. Not changing any of my code, when I switched back to 3.2.0.ga using c3p0pre11, everything worked out fine. So its either a bug with hibernate or c3p0 needs to update to reflect any 3.2.1 changes (I think its the former though).
-los
12：I've been on pre11 and 3.2.1 for a little while and having these problems, usually when reloading web apps from the tomcat manager. Just rolled back to 3.2.0 and haven't had any problems yet.
...全文
请发表友善的回复…
发表回复
t150ckh 2011-03-23
- 打赏
- 举报
算了啦，还是结帐吧！大家对英文都没兴趣啊。
yyx520aiy520 2011-03-22
- 打赏
- 举报
1： 将"max_statements"改为0，然后试一次..我不确定这样做是否对你有效，但是我就是这么做的而且成功了。不同的是我使用的是Firebird.and there was already a related issue.
孤鸿掠影 2011-03-22
- 打赏
- 举报
这么多啊？
a312983516 2011-03-22
- 打赏
- 举报
[Quote=引用 11 楼 bao110908 的回复:]
4：Mark,
4: 马克，
Good luck!
Steve (c3p0 guy)
祝您好运
史蒂夫（c3p0 使用者）
9：hi,
9: 您好，
翻译完毕！
[/Quote]
大哥 咱小本毕业的吧 哈哈 我学俄语还能翻译一个 me
4：Mark,
4: 马克，
Good luck!
Steve (c3p0 guy)
祝您好运
史蒂夫（c3p0 使用者）
9：hi,
9: 您好，
翻译完毕！
[/Quote]
大哥 咱小本毕业的吧 哈哈 我学俄语还能翻译一个 me
t150ckh 2011-03-22
- 打赏
- 举报
[Quote=引用 15 楼 magicluo 的回复:]
8：我实际上到相同的MySQL 5.0.27上使用Hibernate的3.2.1.ga，C3P0的- 0.9.1 - pre6，的mysql - connector - java的- 5.0.4问题运行。 需要说明的是，它发生在ServiceMix的，当我运行它。 这个问题的线程可以在这里找到：http://www.nabble.com/issues-with-deadl ... 12049.h……
[/Quote]多谢。
8：我实际上到相同的MySQL 5.0.27上使用Hibernate的3.2.1.ga，C3P0的- 0.9.1 - pre6，的mysql - connector - java的- 5.0.4问题运行。 需要说明的是，它发生在ServiceMix的，当我运行它。 这个问题的线程可以在这里找到：http://www.nabble.com/issues-with-deadl ... 12049.h……
[/Quote]多谢。
magicluo 2011-03-22
- 打赏
- 举报
8：I'm actually running into the same issue using hibernate-3.2.1.ga, c3p0-0.9.1-pre6, mysql-connector-java-5.0.4 on mysql 5.0.27. The caveat is that it happens when I run it under ServiceMix. The issue thread can be found here: http://www.nabble.com/issues-with-deadl ... 12049.html
I wanted to try upgrading to c3p0-0.9.1-pre7 but the c3p0 site is currently down. If you have any suggestions for me to troubleshoot, please let me know. Thanks in advance.
我在使用c3p0-0.9.1-pre6, mysql-connector-java-5.0.4 on mysql 5.0.27.时居然也碰到了这个问题。当用了ServiceMix就出现了这个警告。 这个问题可访问这里：http://www.nabble.com/issues-with-deadl ... 12049.html
我想升级到c3p0-0.9.1-pre7但是当前的c3p0网站挂了，如果你有其他好的意见，请告诉，先谢了。
-los
9：hi,
please try c3p0-0.9.1-pre11. i think most of these APPARENT DEADLOCK issues are now resolved, though of course you can prove me wrong...
if you have trouble reaching c3p0's website on mchange.com (we're having some network issues), please go to sourceforge.net and search for c3p0. sourceforge hosts the actual releases.
Hi,请试试c3p0-0.9.1-pre11，我认为绝大多数这些死锁的问题现在已经解决了，当然你可以证明我是错的
如果你在访问c3p0网站 mchange.com（我们也有同样的网络故障问题），请访问sourceforge.net，然后搜索c3p0，sourceForge服务器上已经发布了
好运！
good luck!
steve
10：Hi,
I actually switched to pre11 and its still giving me "too many connections" issues. Can I send you my stacktrace directly via email? Thanks.
Hi ,我事实上已经转为使用pre11这个版本，它还是提示我“太多连接”的问题，我可以直接通过邮件发给你这些错误堆栈信息，帮我看看嘛？谢谢。
-los
11：I've got it working. Its actually an issue with Hibernate 3.2.1.ga. Not changing any of my code, when I switched back to 3.2.0.ga using c3p0pre11, everything worked out fine. So its either a bug with hibernate or c3p0 needs to update to reflect any 3.2.1 changes (I think its the former though).
现在已经可以工作了。这确实是hibernate3.2.1ga的问题。不改变任何代码，当我切换回3.2.0ga版本时，使用c3p0 pre11,都没有问题。因此这是hibernate的bug或者c3p0需要升级来适合3.2.1的任何改动
-los
12：I've been on pre11 and 3.2.1 for a little while and having these problems, usually when reloading web apps from the tomcat manager. Just rolled back to 3.2.0 and haven't had any problems yet.
我已经使用pre11和3.2.1.一段时间了，也有这些问题，通常是通过tomcat 管理端程序重新加载应用程序时出现。我返回用3.2.0 ，这些问题再也没出现过.
I wanted to try upgrading to c3p0-0.9.1-pre7 but the c3p0 site is currently down. If you have any suggestions for me to troubleshoot, please let me know. Thanks in advance.
我在使用c3p0-0.9.1-pre6, mysql-connector-java-5.0.4 on mysql 5.0.27.时居然也碰到了这个问题。当用了ServiceMix就出现了这个警告。 这个问题可访问这里：http://www.nabble.com/issues-with-deadl ... 12049.html
我想升级到c3p0-0.9.1-pre7但是当前的c3p0网站挂了，如果你有其他好的意见，请告诉，先谢了。
-los
9：hi,
please try c3p0-0.9.1-pre11. i think most of these APPARENT DEADLOCK issues are now resolved, though of course you can prove me wrong...
if you have trouble reaching c3p0's website on mchange.com (we're having some network issues), please go to sourceforge.net and search for c3p0. sourceforge hosts the actual releases.
Hi,请试试c3p0-0.9.1-pre11，我认为绝大多数这些死锁的问题现在已经解决了，当然你可以证明我是错的
如果你在访问c3p0网站 mchange.com（我们也有同样的网络故障问题），请访问sourceforge.net，然后搜索c3p0，sourceForge服务器上已经发布了
好运！
good luck!
steve
10：Hi,
I actually switched to pre11 and its still giving me "too many connections" issues. Can I send you my stacktrace directly via email? Thanks.
Hi ,我事实上已经转为使用pre11这个版本，它还是提示我“太多连接”的问题，我可以直接通过邮件发给你这些错误堆栈信息，帮我看看嘛？谢谢。
-los
11：I've got it working. Its actually an issue with Hibernate 3.2.1.ga. Not changing any of my code, when I switched back to 3.2.0.ga using c3p0pre11, everything worked out fine. So its either a bug with hibernate or c3p0 needs to update to reflect any 3.2.1 changes (I think its the former though).
现在已经可以工作了。这确实是hibernate3.2.1ga的问题。不改变任何代码，当我切换回3.2.0ga版本时，使用c3p0 pre11,都没有问题。因此这是hibernate的bug或者c3p0需要升级来适合3.2.1的任何改动
-los
12：I've been on pre11 and 3.2.1 for a little while and having these problems, usually when reloading web apps from the tomcat manager. Just rolled back to 3.2.0 and haven't had any problems yet.
我已经使用pre11和3.2.1.一段时间了，也有这些问题，通常是通过tomcat 管理端程序重新加载应用程序时出现。我返回用3.2.0 ，这些问题再也没出现过.
magicluo 2011-03-22
- 打赏
- 举报
这些都很简单的啊 慢慢对着金山词霸看吧 你行的
t150ckh 2011-03-22
- 打赏
- 举报
[Quote=引用 10 楼 amos1989 的回复:]
一两段还可以给你翻译，你拿一大篇来就没动力了
[/Quote]
来一段也行啊，就像火龙果那样。
一两段还可以给你翻译，你拿一大篇来就没动力了
[/Quote]
来一段也行啊，就像火龙果那样。
t150ckh 2011-03-22
- 打赏
- 举报
[Quote=引用 11 楼 bao110908 的回复:]
4：马克，
4：马克，
祝你好运！
史蒂夫（C3P0的家伙）
祝您好运
史蒂夫（C3P0的使用者）
9：嗨，
9：您好，
翻译完毕！
[/Quote]
唉，其实我是在找关于C3P0方面的资料，在我的项目中有用到Hibernate加入了C3P0，在这个项目中又使用到jdbc的查询方式，在得到查询的结果集时，原程序中没把结果集关闭，只是在最后把Session给关闭了？我现在就有一个疑问，这样子做合不合理，把Session关闭了，会不会释放到连接对像。求解啊
4：马克，
4：马克，
祝你好运！
史蒂夫（C3P0的家伙）
祝您好运
史蒂夫（C3P0的使用者）
9：嗨，
9：您好，
翻译完毕！
[/Quote]
唉，其实我是在找关于C3P0方面的资料，在我的项目中有用到Hibernate加入了C3P0，在这个项目中又使用到jdbc的查询方式，在得到查询的结果集时，原程序中没把结果集关闭，只是在最后把Session给关闭了？我现在就有一个疑问，这样子做合不合理，把Session关闭了，会不会释放到连接对像。求解啊
火龙果被占用了 2011-03-19
- 打赏
- 举报
4：Mark,
4: 马克，
Good luck!
Steve (c3p0 guy)
祝您好运
史蒂夫（c3p0 使用者）
9：hi,
9: 您好，
翻译完毕！
4: 马克，
Good luck!
Steve (c3p0 guy)
祝您好运
史蒂夫（c3p0 使用者）
9：hi,
9: 您好，
翻译完毕！
amos1989 2011-03-19
- 打赏
- 举报
一两段还可以给你翻译，你拿一大篇来就没动力了
完美灬缺陷 2011-03-19
- 打赏
- 举报
好的、
龙四 2011-03-18
- 打赏
- 举报
一两段还可以给你翻译，你拿一大篇来就没动力了
网上有很多付费翻译的
网上有很多付费翻译的
代码 2011-03-18
- 打赏
- 举报
金山词霸去吧。。。这么多，看到都头晕了。
齊麟 2011-03-18
- 打赏
- 举报
t150ckh 2011-03-18
- 打赏
- 举报
[Quote=引用 3 楼 zn85600301 的回复:]
有翻译公司~
[/Quote] 能推荐几个不呢？
有翻译公司~
[/Quote] 能推荐几个不呢？
zn85600301 2011-03-18
- 打赏
- 举报
有翻译公司~
zhouluok007 2011-03-18
- 打赏
- 举报
1.尝试或者改变"最大状态" 为0 ,我不确定它会工作,但是它是为我工作 , 不同的是我用的是Firebird数据库并且这里已经有问题显现出来
t150ckh 2011-03-18
- 打赏
- 举报
翻译时，请标明是哪一句，谢谢。
