[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
I agree with you that it is cleaner if all associated resources are closed. If we can be
sure about that (via the proxied Statement) thats fine. But what's about the 3.6.x
release? Are there no further maintenance releases planned?
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira