Announcement Announcement Module
Collapse
No announcement yet.
Spring Compatibility with Hibernate 4.1.9 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Compatibility with Hibernate 4.1.9

    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.

    Code:
    public <T> T execute(StatementCallback<T> action) throws DataAccessException {
    		Assert.notNull(action, "Callback object must not be null");
    
    		Connection con = DataSourceUtils.getConnection(getDataSource());
    		Statement stmt = null;
    		try {
    			Connection conToUse = con;
    			if (this.nativeJdbcExtractor != null &&
    					this.nativeJdbcExtractor.isNativeConnectionNecessaryForNativeStatements()) {
    				conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
    			}
    			stmt = conToUse.createStatement();
    			applyStatementSettings(stmt);
    			Statement stmtToUse = stmt;
    			if (this.nativeJdbcExtractor != null) {
    				stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt);
    			}
    			T result = action.doInStatement(stmtToUse);
    			handleWarnings(stmt);
    			return result;
    		}
    		catch (SQLException ex) {
    			// Release Connection early, to avoid potential connection pool deadlock
    			// in the case when the exception translator hasn't been initialized yet.
    			JdbcUtils.closeStatement(stmt);
    			stmt = null;
    			DataSourceUtils.releaseConnection(con, getDataSource());
    			con = null;
    			throw getExceptionTranslator().translate("StatementCallback", getSql(action), ex);
    		}
    		finally {
    			JdbcUtils.closeStatement(stmt);
    			DataSourceUtils.releaseConnection(con, getDataSource());
    		}
    Hibernate 4.1.9 now proxies jdbc statements and the exception converter now kicks in which throws a runtime exception instead of a checked one. For e.g. Instead of SQLException now a runtime exception is thrown - SQLGrammerException.

    Spring probably should be handling this hibernate change, right?

  • #2
    Why? Why should the JDBC stuff properly handle HIbernate changes... This code shouldn't even be used/trigger. If you are messing around with native SQL of a hibernate connection I suggest stop doing that and simply inject a JdbcTemplate and associate that with the same datasource that Hibernate uses...

    Else create a NativeJdbcExtractor which unwraps the proper connection (I hope that hibernate uses the standard JDBC4.0 mechanism and then you can use the Jdbc4NativeJdbcExtractor out of the box).

    Comment


    • #3
      I think I didn't detail my problem statement correctly.

      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 of SQLException). Since a runtime exception is thrown, the code in the catch block (above) never gets executed.

      Does that help?

      Comment

      Working...
      X