HHH000387 休眠警告是什么意思？
我刚刚更新到 Hibernate 4.0，并在我的日志文件中看到警告消息：
HHH000387：ResultSet 的语句未注册
。这是什么意思？我应该担心吗？
I have just updated to Hibernate 4.0 and am seeing the warning message :
HHH000387: ResultSet's statement was not registered
in my log files. What does this mean, and should I be worried?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不会太担心。无论如何，API 用户似乎无法避免此消息。日志记录是在 org.hibernate.engine.jdbc.internal.JdbcResourceRegistryImpl 中完成的。根据 文档：
简单看一下代码就知道，这样的消息在两种情况下会被记录：
I would not worry too much. In any case it looks like it is not in API's users hands to avoid this message. Logging is done in the org.hibernate.engine.jdbc.internal.JdbcResourceRegistryImpl. According documentation:
Short look to the code tells, that such a message is logged in two situations:
查看引发此错误的 JdbcResourceRegistryImpl 类的源代码，我个人认为将其记录在 WARN 级别是过度的；它最多应该是 INFO，除非有一种方法可以将所有语句隐式注册为 Hibernate/framework 配置的一部分。
我不清楚为什么应该注册
Statement，但如果这只是 Hibernate 内部工作的问题，那么定期警告 API 用户这就是一个错误，对吗？Looking at the source for the
JdbcResourceRegistryImplclass that throws this error, I personally think having it log at WARN level is excessive; it should be INFO at most, unless there's a way to have allStatements implicitly registered as part of a Hibernate/framework configuration.It's not clear to me why a
Statementshould be registered, but if it's only a concern of the inner workings of Hibernate then routinely warning API users about it is a bug, right?此日志消息表明
ResultSet.getStatement()未返回最初要求创建ResultSet的Statement。 （它也可能表明内存泄漏。）使用 JDBC 包装器时可能会发生这种情况，因为有两个Statement对象：包装器/装饰器和底层Statement。在我的项目中，我有自己的 JDBC 包装器用于测试。我通过确保
getStatement()返回原始Statement代理（不是新代理），而不是委托给底层ResultSet（这将返回底层Statement）。任何产生类似警告的 JDBC 包装器都可能使用类似的修复方法。 （类似的问题和修复可能适用于方法
Statement.getConnection()。）顺便说一下，这里有一个关于此日志记录的错误报告：https://hibernate.atlassian.net/browse/HHH-8210
This log message is a sign that
ResultSet.getStatement()doesn't return theStatementwhich was originally asked to create theResultSet. (It may also indicate a memory leak.) This can happen when using a JDBC wrapper, because there are twoStatementobjects: a wrapper/decorator and the underlyingStatement.In my project, I have my own JDBC wrapper for testing. I fixed this warning in my
ResultSetwrapper by ensuring thatgetStatement()returns the originalStatementproxy (not a new proxy), rather than delegating to the underlyingResultSet(which would return the underlyingStatement).Any JDBC wrapper which is producing similar warnings could probably use a similar fix. (A similar problem and fix may apply to the method
Statement.getConnection().)By the way, there is a bug report for this logging here: https://hibernate.atlassian.net/browse/HHH-8210
你配置了连接池吗？我也收到同样的警告。但是如果我在我的 Maven 依赖项中添加了 c3p0 并在 hibernate.cfg.xml 中正确配置了它。警告消失。
Did you configured connection pool? I've got the same warning. But if I added c3p0 in my maven dependency and get it correctly configured in hibernate.cfg.xml. The warning disappears.
就我而言，此警告表明存在巨大的性能泄漏！
我有带有 @oneToOne 映射的 hibernate POJO 对象。对于一张表，它工作正常并且没有警告：它向 MySQl 服务器发送一个请求以获取所有记录，然后向每个连接表发送一个请求。
对于 POJO，我收到此错误（当未找到 @oneToOne 时）：它发送一个初始请求以获取所有对象的列表，然后每次发送针对每条记录的映射表的新请求。
假设我的测试数据库中有 2000 条记录。和 3 个 @oneToOne 映射表。
在良好的情况下，它会发送 1 个获取列表的请求和 3 个获取映射表的请求。
如果出现警告，它会发送 1 个获取列表的初始请求。然后发送 3 个请求以获取数据库中 2000 条记录中每条记录的映射信息！因此，每个用户每次调用 @Controller (Spring MVC) 都会有 1999*3=5997 个额外请求。
当 Web 应用程序和 MySQL 服务器位于同一服务器上时，我没有注意到这一点。
In my case this warning was an indicator of huge performance leak!
I have hibernate POJO objects with @oneToOne mapping. For one table it works fine and no warnings: it sends one request to MySQl server for getting all the records and then for one requests for each joined table.
For POJO where I'm getting this error (when no @oneToOne found): it sends one initial request for getting a list of all objects and then every time send new and new requests for mapped tables for each record.
So, let's say I have 2000 records in my test DB. And 3 @oneToOne mapped tables.
In a good case, it sends 1 request for getting a list and 3 requests for getting mapped tables.
In the case of a warning, it sends 1 initial request for getting list. Then send 3 requests for getting mapped info for each of 2000 records in DB! So 1999*3=5997 additional requests for each user for each call the @Controller (Spring MVC).
I hadn't noticed it while the web application and MySQL server were on the same server.