[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Florian Probst commented on HHH-2455:
-------------------------------------
We currently have OutOfMemory issues by using the DbTimestampType.seed() Method very
frequently for querying the current database timestamp. This is uesed in a Thread who
never closes his current Session and because a clear() does not clean the opened
ResultSets the memory is never deallocated.
As alread said, calling closeQueryStatement() instead of closeStatement() would solve the
problem.
"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
Original Estimate: 1 hour
Remaining Estimate: 1 hour
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira