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