Announcement Announcement Module
Collapse
No announcement yet.
Why would you ever want to use HibernateInterceptor? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why would you ever want to use HibernateInterceptor?

    A colleague of mine has suggested that we should probably replace any instance where we use SessionFactoryUtils/HibernateInterceptor to get the session with a HibernateCallback instead. I think I agree! It seems like the .execute does a lot of extra checks, expecially with the TransactionSynchronizationManager, as per below:

    Code:
    	public Object execute(HibernateCallback action) throws DataAccessException {
    		Session session = (!isAllowCreate() ?
    				SessionFactoryUtils.getSession(getSessionFactory(), false) :
    				SessionFactoryUtils.getSession(
    						getSessionFactory(), getEntityInterceptor(), getJdbcExceptionTranslator()));
    		boolean existingTransaction = TransactionSynchronizationManager.hasResource(getSessionFactory());
    		if (!existingTransaction && getFlushMode() == FLUSH_NEVER) {
    			session.setFlushMode(FlushMode.NEVER);
    		}
    		try {
    			Object result = action.doInHibernate(session);
    			flushIfNecessary(session, existingTransaction);
    			return result;
    		}
    		catch (HibernateException ex) {
    			throw convertHibernateAccessException(ex);
    		}
    		catch (SQLException ex) {
    			throw convertJdbcAccessException(ex);
    		}
    		catch (RuntimeException ex) {
    			// callback code threw application exception
    			throw ex;
    		}
    		finally {
    			SessionFactoryUtils.closeSessionIfNecessary(session, getSessionFactory());
    		}
    	}
    Does it make sense to ever leverage the HibernateInterceptor, especially when dealing with CMT and distributed transactions? It seems like the HibernateCallback is the better way to go in light of this code.

    Thanks,
    Lou
Working...
X