Cascade behavior during flush

VampBoy · **Posted:** Wed Nov 14, 2007 2:38 pm

Hibernate version: 3.2.5

Name and version of the database you are using: Oracle 10g

Question regarding the cascade behavior during the flushEverythingToExecution. I've got a listener set up for saveOrUpdate events and noticed that it is firing way more than I would have expected.

It looks like during the cascading of the associations it will always fire a saveUdate event even if nothing on the entity has changed. i.e. in my case I am doing a bunch of fetches but then during the commit of the transaction a load of saveUpdate events are fired. Is this normal?

It looks like the AbstractFlushingEventListener is going to fire a cascade which on anything that is in a MANAGED state which will in turn trigger a saveUpdate. MANAGED is the default for anything loaded during the session I believe.

Code:

   private void prepareEntityFlushes(EventSource session) throws HibernateException {
      
      log.debug("processing flush-time cascades");

      final Map.Entry[] list = IdentityMap.concurrentEntries( session.getPersistenceContext().getEntityEntries() );
      //safe from concurrent modification because of how entryList() is implemented on IdentityMap
      final int size = list.length;
      final Object anything = getAnything();
      for ( int i=0; i<size; i++ ) {
         Map.Entry me = list[i];
         EntityEntry entry = (EntityEntry) me.getValue();
         Status status = entry.getStatus();
         if ( status == Status.MANAGED || status == Status.SAVING ) {
            cascadeOnFlush( session, entry.getPersister(), me.getKey(), anything );
         }
      }
   }

The cascade on flush gets called:

Code:

   private void cascadeOnFlush(EventSource session, EntityPersister persister, Object object, Object anything) 
   throws HibernateException {
      session.getPersistenceContext().incrementCascadeLevel();
      try {
         new Cascade( getCascadingAction(), Cascade.BEFORE_FLUSH, session )
         .cascade( persister, object, anything );
      }
      finally {
         session.getPersistenceContext().decrementCascadeLevel();
      }
   }

The cascading action is a SAVE_UPDATE action which does the following:

Code:

      public void cascade(EventSource session, Object child, String entityName, Object anything, boolean isCascadeDeleteEnabled)
      throws HibernateException {
         if ( log.isTraceEnabled() ) {
            log.trace( "cascading to saveOrUpdate: " + entityName );
         }
         session.saveOrUpdate(entityName, child);
      }

Which then ends up triggering all of the saveUpdate listeners.

Is this required? It would seem to me that it should check the dirtyness of an entity before calling update on it but am I missing something? It just seems strange to me that it would process all of the saveUpdates on a session that contains unmodified entities.

cudennec · **Joined:** Tue Sep 19, 2006 6:47 am **Posts:** 15

I have the same problem; I'd be interested in anything you found out :)

VampBoy · **Posted:** Wed Nov 21, 2007 12:38 pm

I'm glad I'm not alone. I might just kick this up to JIRA to see if it's by design or if it denotes an underlying issue.

cudennec · **Joined:** Tue Sep 19, 2006 6:47 am **Posts:** 15

I got my problem solved by using a "PreUpdateEventListener" and not a "SaveOrUpdateEventListener". This listener seems to be called only if an entity was changed. See if this also works for you.

VampBoy · **Posted:** Wed Nov 28, 2007 1:16 pm

cudennec wrote:

I got my problem solved by using a "PreUpdateEventListener" and not a "SaveOrUpdateEventListener". This listener seems to be called only if an entity was changed. See if this also works for you.

Yeah, I believe that will only fire if the action is executed. I'm not having a problem per se but it was just something I had noticed while rigging up a more intensive auditing log for our app.

steenk · **Posted:** Wed Dec 05, 2007 11:17 am

If you use a list hibernate fires updates to reorder the index.

But why both the key column and the index column are first nullified beats me. This 'provokes' a lot of contraint checks on the DB side to fail!