I am working on upgrading an application from Hibernate 2 to Hibernate 3.2. There is a note in the Hibernate 3.1 migration guide that has me worried.
Quote:
Important known issue: If you call session.connection() in Hibernate 3.1.0, you are responsible to close() the JDBC Connection yourself!
What is this issue exactly? Is it strictly dependent on the connection pool implementation? If so, how?
Say for example I have the following pseudocode:
Code:
try{
statement = session.connection().prepareStatement("insert statement here");
statement.setString(1, "Some string");
...
statement.execute();
session.connection().commit()
catch (Exception e) {
//logerror
}
finally{
try {
if(statement!=null) {
statement.close();
}
if(session!=null) {
session.close();
}
} catch (Exception e) {
//logerror
}
}
Would I be in danger of leaking open connections?
I'm just trying to understand the issue more because the code I am working on uses session.connection() a lot and I need to be able to analyze how big of a risk this is.
Setup is an Oracle 11g database using the thin Oracle JDBC driver; Java 1.6; Hibernate 3.3.2. The datasource being used is oracle.jdbc.pool.OracleConnectionPoolDataSource.
UpdateI was looking through more of the Hibernate documentation and I found what appears to be a conflicting statement in the reference guide. From section 10.4.4 of the Hibernate 3.3.2 reference manual:
Quote:
10.4.4. Queries in native SQL
You may express a query in SQL, using createSQLQuery() and let Hibernate take care of the mapping from result sets to objects. Note that you may at any time call session.connection() and use the JDBC Connection directly. If you chose to use the Hibernate API, you must enclose SQL aliases in braces:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/objectstate.html#objectstate-querying-nativesql
Login
FAQ
Search