Announcement Announcement Module
Collapse
No announcement yet.
Sequence of CRUD operations in a unique transaction Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sequence of CRUD operations in a unique transaction

    Hi all.

    I want to know how a sequence of crud operations are executed in a
    transaction.

    I mean, suppose that in a transaction u have 3 update , 2 save and 4 remove calls.

    In what sequence these operations are done.

    I have a problem using transaction (implementing transactionproxyfactorybean) .

    There is an update and a save query on a table. The update should be done before save is called to make sure that there is no violation key exception.

    But because the save executes before update (why?)
    i get such an exception.

    Is there anyone that know how hibernate (or spring)
    optimizes these sequencesand runs them.

    Sincerely,

    Narsis.

  • #2
    Hibernate may trigger, behind the scenes, an update to database before a certain operations.
    Can you post your config and test case ?

    Comment


    • #3
      Sequence of CRUD operations in a unique transaction

      Hi.

      This is part of applicationContext.xml file :

      <b>
      <bean id="myclassdao" parent="proxyFactoryBean">
      <property name="proxyInterfaces">
      <value>com.dpi.dal.dao.MyClassDAO</value>
      </property>
      <property name="target">
      <bean class="com.dal.dao.impl.MyClassDAOImpl" >
      <property name="sessionFactory">
      <ref bean="mySessionFactory"/>
      </property>
      </bean>
      </property>
      </bean>
      <bean id="imyclassservice" parent="txProxyTemplate">
      <property name="target">
      <bean class="com.dal.service.impl.MyClassServiceImpl" >
      <property name="myClassDAO">
      <ref bean="myclassdao"/>
      </property>
      </bean>
      </property>
      </bean>


      <bean id="imyclasstransactionservice" class="org.springframework.transaction.interceptor .TransactionProxyFactoryBean">
      <property name="transactionManager">
      <ref local="myTransactionManager"/>
      </property>
      <property name="target">
      <bean class="com.dpi.dal.service.impl.MyClassServiceImpl " >
      <property name="myClassDAO">
      <ref bean="myclassdao"/>
      </property>
      </bean>
      </property>
      <property name="transactionAttributes">
      <props>
      <prop key="*">PROPAGATION_REQUIRED, -Exception</prop>
      </props>
      </property>
      </bean>
      </b>

      and this is a test method :

      <b>
      public void insertNewNode(MyClass oldClass)
      {
      // There is a unique constraint on field1
      MyClass newMyClass = new MyClass();
      newMyClass.setField1(null);
      newMyClass.setField2(oldClass.getField2());
      newMyClass.setField3(oldClass.getField3());
      newMyClass.setField4(oldClass.getField4());

      oldClass.setField1(new java.util.Date());

      myClassDAO.update(oldClass);
      myClassDAO.save(newMyClass);
      return;
      }
      </b>

      but everytime the method is called, save is executed first and it throws
      a violation exception.

      Sincerely,

      Narsis.

      Comment


      • #4
        Updates/deletes are executed at the very end of the transaction, just before the commit. Inserts are (usually) executed at the moment when save() is executed because Hibernate needs to get hold of the generated key as soon as possible.

        If you need to control the order of the sql statements you have to do manual Session.flush() at some points.

        Comment


        • #5
          All of the operations are executed at the very end, but not in the
          order they are called.

          And another problem. If you flush your session everywhen you want, then
          managing the transaction will become hard.

          I mean, if for example the transaction containes ten crud operations, and
          you flush the session after forth command, then may be you need to rollback
          the operations and it's hard after committing them.

          What do you think about it?

          Sincerely,

          Narsis.

          Comment


          • #6
            I'm not sure about this. Shouldn't this all commit or all rollback? If that's not the case then you need to commit each bit in a different transaction.
            Last edited by karldmoore; Aug 27th, 2007, 03:55 PM.

            Comment

            Working...
            X