, not positive, but ResultSets could potentially be wrapped as well. Open a new JIRA with details/context?

Forgive me, it appears our issue was with a near identical log but not the same issue "JdbcCoordinatorImpl - HHH000386: ResultSet had no statement associated with it, but was not yet registered". It does appear that the log issue above has been resolved in 4.2.3. Is there a chance that the log "JdbcCoordinatorImpl - HHH000386: ResultSet had no statement associated with it, but was not yet registered" will be switched to a debug level at some point? Or is it abnormal to be seeing that log repeatedly?

We have updated our Hibernate version to 4.2.3.Final and are still seeing this log at the WARN level in our log files. Did the fix possibly not make it into the 4.2.3 release?

, I understand your point and agree that under some circumstances (custom JDBC wrappers, etc.), a warning might be useful during development. But in my opinion, there are more situations where JDBC drivers and connection pools cause the excessiveness. It's the usual balancing act, and here I think DEBUG is the most appropriate. If many others think otherwise, keep up the discussion.

Isn't this log message an indicator that JdbcCoordinatorImpl's HashMap "xref" may be retaining ResultSets and Statements which should have been removed (ie a memory leak)? I think this log message does deserve to be a warning, but it might be better to log it only once per session. If I am correct about the memory leak, the wording of the message should probably be more emphatic and more helpful too!

I encountered this warning when using a JDBC wrapper which returned unwrapped Statements from ResultSet.getStatement(), even though the ResultSet was created via a wrapped Statement. The fix was for the JDBC wrapper to ensure ResultSet.getStatement() returns the wrapped Statement. Without the warning message, I wouldn't have known there was a problem until much later. See http://stackoverflow.com/a/17480927/14379