New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JdbcTemplate compatibility with Hibernate 4.1.9's proxied JDBC Statements [SPR-10267] #14901
Comments
Juergen Hoeller commented That catch block in From my perspective, proxied JDBC Statements should be throwing proper SQLExceptions. If Hibernate chooses to bypass the signatures there and throw RuntimeExceptions instead, then well, Spring's SQLException translation simply doesn't kick in. Juergen |
Amit commented So you are hinting that hibernate should have been backward compatible and they should change to throw SQLException's as they did earlier? |
Juergen Hoeller commented Well, yes - but my point is also that the only negative behavior is a lack of exception translation. Or are you seeing any kind of resource leak? Juergen |
Amit commented No. There isn't a resource leak. The finally block closes the resources. |
Amit commented I discussed this issue on the hibernate dev forum. They mention that since this was an major release (4.x), such changes (i.e. throwing a unchecked exception instead of a checked one in our case) are expected and the client code (in this case - spring) should be modified to resolve the issue. Kindly let me know your thoughts |
Juergen Hoeller commented We might be able to generically check for unchecked exceptions that have a SQLException root cause, invoking our SQLExceptionTranslator that way. However, I do believe that Hibernate is breaking the JDBC API contract by throwing unchecked exceptions there. JDBC is clearly designed to always throw SQLExceptions, and a JDBC proxying mechanism is supposed to comply with that rule since otherwise, the use of such a proxying mechanism isn't transparent to client code anymore. Juergen |
Amit commented I agree. The proxying mechanism is not transparent. It's hard to convince the hibernate team :). Hope to see the spring fix soon! |
Juergen Hoeller commented The changes required to JdbcTemplate and other places where we're calling into JDBC API are somewhat involved and therefore not really a candidate for the 3.2.x line. We'll reconsider for 4.0.x. For the time being, a good solution might be to define a PersistenceExceptionTranslationPostProcessor and to mark your JDBC-accessing classes with the Juergen |
Amit commented Any plans to fix this issue? I just came across the migration guide for spring 4. "The org.springframework.orm.hibernate3 package will be deprecated as of Spring Framework 4.1. We keep fully supporting it for the time being against Spring Framework 4.0. However, we recommend a timely upgrade to Hibernate 4.2/4.3" To upgrade to hibernate 4.x, we would need this issue to be fixed. Can you please prioritize this? |
Juergen Hoeller commented This seems to be fixed in Hibernate itself as of 4.2: https://hibernate.atlassian.net/browse/HHH-7902 As far as we can tell from the current Hibernate 4.2 implementation of the connection() method, we properly get the native Connection back there. Please try Hibernate 4.2.8 and let me know whether any problems remain... Juergen |
Amit opened SPR-10267 and commented
I upgraded my project with the latest spring and hibernate releases (spring 3.2.1 and hibernate 4.1.9) but they seem to be incompatible. One of the changes are part of spring's jdbc framework.
We use a combination of JPA (
HibernateJPADialect
&JpaTransactionManager
) & JDBC in our application. For mapped entities JPA is used (included JPQL queries) while for non mapped objects direct JDBC is used.Spring binds the data source resource with the connection handle created through hibernate jpa dialect. This means any request to create a connection gets delegated to hibernate which proxies connections and statements. Hence when a connection is requested for executing a query through spring's jdbc template we get a proxied connection.
Hibernate 4.1.9 proxies jdbc statements (which was not done in the earlier versions at least 3.6). The proxy throws runtime exception instead of checked exception (
SQLGrammerException
instead ofSQLException
is thrown for e.g. in scenarios where a select query is executed on a table which does not exists). Since a runtime exception is thrown, the code in the catch block ofjdbc.executeQuery()
never gets executed.Affects: 3.2.1
Reference URL: http://forum.springsource.org/showthread.php?134595-Spring-Compatibility-with-Hibernate-4-1-9&p=437518
0 votes, 5 watchers
The text was updated successfully, but these errors were encountered: