java.sql.SQLException:无法在 60 秒内获取锁定
我跟踪这个错误已经有一段时间了,它会以不规则的方式不可预测地发生,而且我现在还没有找到重现它的方法。
我们的环境
- linux centos 5.3 托管一台 jboss 5.1 应用程序服务器
- linux centos 5.3 托管一台 oracle 10g XE db
- windows server 2003 R2 托管另一台 oracle 10g XE db
编程环境
- seam 2.1
- hibernate
- JSF 1.2
大多数错误发生在“应用程序”范围接缝组件上,但它也发生在其他地方。
Wea 使用 XA 数据源来访问数据库。
看来这也是 jboss 5.1 中的某种错误 看这里,但我们不这样做有持续 60 秒的查询或请求。
出现此类错误的可能原因是什么?
错误的最终堆栈跟踪:
Caused by: java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@1d314d
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.tryLock(BaseWrapperManagedConnection.java:267)
at org.jboss.resource.adapter.jdbc.WrappedConnection.lock(WrappedConnection.java:79)
at org.jboss.resource.adapter.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:237)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:534)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:452)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1573)
at org.hibernate.loader.Loader.doQuery(Loader.java:696)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
I'm tracking this error for a while now, it hapens on irregular basis unpredictibly and I haven't find a way to reproduce it for now.
Our environment
- linux centos 5.3 hosting one jboss 5.1 app server
- linux centos 5.3 hosting one oracle 10g XE db
- windows server 2003 R2 hosting another oracle 10g XE db
Programming environment
- seam 2.1
- hibernate
- JSF 1.2
Most of this errors happens on a "APPLICATION" scope seam component, but it also happened elswhere.
Wea are using XA-datasource to access the databases.
It appeares that tis is also some sort of a bug in jboss 5.1 look here, but we do not have queries or requests that last 60 seconds.
What could be the possible reason for this kind of errors?
The final stack trace of the error:
Caused by: java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@1d314d
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.tryLock(BaseWrapperManagedConnection.java:267)
at org.jboss.resource.adapter.jdbc.WrappedConnection.lock(WrappedConnection.java:79)
at org.jboss.resource.adapter.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:237)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:534)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:452)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1573)
at org.hibernate.loader.Loader.doQuery(Loader.java:696)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以在 app-ds.xml 文件中执行一些技巧。如果你有的话是吗?
例如,如果您正在运行 mysql,您可以编写
您还应该查看数据库的配置文件,也许您可以在那里调整一些设置。例如,
wait_timeout
、max_connections
等。特别是你可以考虑增加后者。也许你有很多空闲的sql连接没有做任何事情,当达到池时,它会等待直到达到一个,然后你得到这个异常?
还要记住,应用程序范围的组件是线程安全的。因此,请确保尽可能限制应用程序范围的组件和会话组件。
如果适用,最好使用事件和对话范围的组件。
There are some tricks you can do in your app-ds.xml file. If you have one that is?
For instance, if you are running mysql you can write
You should also look in the config file for your database, and maybe you can tweak some settings there. For instance,
wait_timeout
,max_connections
etc. Especially you can consider increasing the latter.Maybe you have many idle sql connections that are not doing anything, and when the pool is reached, it will wait until one is reached, and then you get this exception?
Also remember that Application scoped components are thread safe. Thus make sure that you limit application scoped components and session components as much as possible.
Better to use Event and Conversation scoped components where applicable.