Announcement Announcement Module
No announcement yet.
hibernate auto flush or custom transaction proxy? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • hibernate auto flush or custom transaction proxy?

    i use a custom OpenSessionFilter
    public class OpenSessionFilter extends OpenSessionInViewFilter{
        final static Logger logger = Logger.getLogger(OpenSessionFilter.class.getName());
        protected Session getSession(SessionFactory sessionFactory) throws DataAccessResourceFailureException {
            Session session = SessionFactoryUtils.getSession(sessionFactory, true);
    		return session;
    as what you see, i remove session.setFlushMode(FlushMode.NEVER);
    every thing works fine

    but i see some project ,such as confluence,petclinc sample
    they all use TransactionProxy to do custom transaction on daos like this
        <bean id="groupDao" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
            <property name="transactionManager">
                <ref local="transactionManager"/>
            <property name="target">
                <ref local="confluenceGroupDaoTarget"/>
            <property name="transactionAttributes">
                    <prop key="*">PROPAGATION_REQUIRED</prop>
    here is my question:
    what's the different between there two ways
    which is good,and would second way get a poor performace?
    how to choose the apropos way?

    in confluence, some dao seems use way 1 (auto-flush),some use way 2(tran proxy)
    it really confuse me...

  • #2
    i know

    hibernateTemplate doesnt implement Rollback,it need to be used with TransactionTemplate

    transactionManager did implement rollback operation

    am i right?


    • #3
      The OpenSessionInViewFilter is not a replacement for using transactional proxies around your code (or programmatic transactions, which while less convenient than declarative transactions, work effectively the same).

      All the filter does is open the session ahead of time, so when the view layer calls down into the transactionally wrapped service layer, any returned object graphs can still have lazy relationships traversed.

      The default flushmode=never in the filter is appropriate, since what you want is your transaction to flush (it will), and then you don't want to accidentally flush at the end of the request any non-transactional changes that might have been made on the returned data by the view layer.