-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: PostUpdateListener + LAZY 1:m:n + Flush = AssertionFailure
PostPosted: Mon Mar 05, 2007 5:14 am 
Beginner
Beginner

Joined: Mon Sep 12, 2005 3:27 am
Posts: 48
We are using jboss 4.2CR1 and Hibernate 3.2.1 and get an Assertion Error on flushing when touching LAZY 1:m:n relations in an PostUpdateListener, even when only updating a simple property on the 1-side Entity of this relation and do NOTHING on the relation itself.

Quote:
09:23:12,699 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection [com.xyz.server.core.ejb.entity.equipment.EquipmentEntity.repairs] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)


There seems to be a bug, when processing the n-side of a 1:n relation [= PersistentCollection I get for a 1:n relation via event.getOldState() or event.getState()] inside an Event-Listener, when the entities of this PersistentCollection have by themselve further 1:n relations to a 3rd-entity.

It seems a little bit complicated, to reproduce this failure:

You need 3 enties with relations like following:
Code:
EquipmentType  <---> Equipment <----> Repairs

    1         :      n          1        :      m


If we update only a SIMPLE property (not relation) in EquipmentType, it claims, that flush() [inside PostupdateListener] has not processed the PersistentCollection of Repairs in Equipment!

We use the following PostUpdateEventlistener:

Code:
package com.qualitype.lims.server.common.audit;


/**
* *
* This is the base for all AuditEventListeners. Dependent of the exact event
* it's examing the difference between old and new object. This differences were
* logged into the datbase via
* @see(AuditRecordEntity.class)
*
*/
public abstract class AuditBaseListener extends BaseListener implements
      CallbackHandlerConsumer {

   EntityCallbackHandler callbackHandler;

   public void setCallbackHandler(EntityCallbackHandler handler) {
      this.callbackHandler = handler;
   }



   /**
    * audits the changes of an entity after an update of this entity
    *
    * @param event -
    *            the PostUpdate event
    */
   protected void audit(PostUpdateEvent event) {
      // audit update events
      auditChanges(DatabaseOperation.UPDATE, event.getOldState(), event
            .getState(), event.getPersister().getPropertyNames(),
            (AuditableEntity) event.getEntity());
   }


   /**
    * examines old and new object and logs the changes of persistent data into
    * an audit-record
    *
    * @param event
    *            the type of event (INSERT, UPDATE, DELETE) being logged.
    */
   @SuppressWarnings( { "boxing", "nls" })
   private void auditChanges(DatabaseOperation event, Object[] oldValues,
         Object[] newValues, String[] properties, AuditableEntity entity) {

      // synchronized (getClass()) {
      // get a new database Session
      Session session = getCurrentSession();

      try {

         // create base AuditRecord
         AuditRecordEntity auditRecord = new AuditRecordEntity(
               AuditableEntity.getCurrentUser(), entity, event);

         // Iterate through all the fields in the object
         for (int ii = 0; ii < properties.length; ii++) {

            AuditChangedFieldEntity auditFieldRecord = null;
            String beforeValue = "";
            String afterValue = "";

            if (properties[ii].equals("version")
                  || properties[ii].equals("createdBy")
                  || properties[ii].equals("updatedBy")
                  || properties[ii].equals("createdTime")
                  || properties[ii].equals("updatedTime"))
               continue;

            if (oldValues != null)
               beforeValue = getFormatedString(oldValues[ii]);

            if (newValues != null)
               afterValue = getFormatedString(newValues[ii]);

            if (event.equals(DatabaseOperation.UPDATE)) {
               if (afterValue.equals(beforeValue)) {
                  // Values haven't changed so loop to next property
                  continue;
               } else {
                  auditFieldRecord = new AuditChangedFieldEntity(
                        properties[ii], beforeValue, afterValue);
               }
            } else if (event.equals(DatabaseOperation.DELETE)) {
               auditFieldRecord = new AuditChangedFieldEntity(
                     properties[ii], beforeValue, afterValue);
            } else if (event.equals(DatabaseOperation.INSERT)) {
               // brand new collections will appear as [-1, -1, -1, -1,
               // -1,
               // -1, -1, -1, -1, -1]
               // unless we get all the id values after the new owning
               // entity has been persisted
               if (afterValue.contains("-1")) // -1 //$NON-NLS-1$
               // indicates unsaved value
               {
                  Integer count = Arrays.asList(properties).indexOf(
                        properties[ii]);
                  Object object = newValues[count];
                  if (object instanceof Collection) {
                     afterValue = (toString((Collection) object));
                  }
               }
               auditFieldRecord = new AuditChangedFieldEntity(
                     properties[ii], beforeValue, afterValue);
            }
            if (auditFieldRecord != null) {
               // database linking
               auditFieldRecord.setAuditRecord(auditRecord);
               auditRecord.getChangedFields().add(auditFieldRecord);
            }
         }
         // save auditRecord and cascading save auditFieldRecords
         session.save(auditRecord);

      } catch (HibernateException e) {
         e.printStackTrace();
         throw new CallbackException(e);
      } finally {
         if (session != null) {
            /*
             * there seems to be a change in Hibernate since 3.1 so default
             * option autoFlush=true for JTA-SessionContext is not working
             * anymore. We have explicitly to flush the session.
             *
             * http://opensource.atlassian.com/projects/hibernate/browse/HHH-2259?page=all
             */
            session.flush();
            // TODO: session.close() ?
            session = null;
         }
      }
   }

   protected static Session getCurrentSession() throws HibernateException {
      if (sessionFactory == null) {
         try {
            InitialContext ctx = new InitialContext();
            sessionFactory = (SessionFactory) ctx
                  .lookup("java:hibernate/SessionFactory");
         } catch (NamingException e) {
            e.printStackTrace();
            throw new HibernateException(e);
         }
      }
      /**
       * INFO: in case of a JTA datasources (like mostly under jboss), the
       * implenatation-class for Interface "CurrentSession" is
       * JTACurrentSession, which always returns a session(=connection) from
       * the jboss pool. These session should automatically be configured for
       * autoFlush and autoClose.
       */
      // return sessionFactory.getCurrentSession();
      return sessionFactory.openSession(sessionFactory.getCurrentSession()
            .connection());
   }
}



If we iterate through Event.getOldState() and getting the Equipment-Collection associated with EquipmentType and do something simple with this collection, for example like following way in the EventListener:
Code:
   private String getFormatedString(Object object) {
      String value = ""; //$NON-NLS-1$
      try {
         if (object != null) {
            value = (object instanceof Collection) ? toString((Collection) object)
                  : toString(object);
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
      return value;
   }

   private String toString(Collection collection) {
method-versions
      StringBuilder str = new StringBuilder(START);

      for (Object object : collection) {
         str.append(toString(object));
         str.append(DELIM);
      }
      if (!collection.isEmpty())
         str.delete(str.lastIndexOf(DELIM), str.length());
      str.append(END);
      return str.toString();
   }
.
.
.


Hibernate will then throw the AssertionFailure:
Quote:
09:23:12,699 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection [com.xyz.server.core.ejb.entity.equipment.EquipmentEntity.repairs] was not processed by flush()


This failure seems only go away, if:
- I comment out the whole method toString(Collection collection) - indicating a reason for the assertion-failure is inside this method
or
- we set the 1:M relation to EAGER or CASCADE-STYLE to MERGE.

Finally: There seems to be a bug, when processing the n-side of a 1:n relation inside an Event-Listener, when the entities of the n-side collection have by themselve further 1:n relations to a 3rd-entity? Any hint to avoid this assertion Failure ?

Jboss 4.2CR1
Hibernate 3.2.1
EJB3


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 24, 2007 4:17 am 
Beginner
Beginner

Joined: Sun Jun 13, 2004 9:49 pm
Posts: 38
We are seeing this exact problem.

I am writing an audit entity in a postUpdate listener. We are not touching anything to do with the entities that caused the listener to fire. Even if we just get an entity (which causes a flush), we get this error.

Anyone know a workaround, or if the bug has been fixed. Is it even in Jira?

hibernate-annotations-3.2.1.ga
hibernate-core-3.2.3.ga

Not in JBoss. This is just with Unit tests.

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 29, 2007 10:50 am 
Beginner
Beginner

Joined: Sun Jun 13, 2004 9:49 pm
Posts: 38
Any help? It seems that anything with events in gets ignored. Is this because noone uses/understands them?

Can soone point to some info on how to use events correctly. More importnantly how to write entities whilst in a postXXX listener.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2007 4:48 am 
Beginner
Beginner

Joined: Mon Sep 12, 2005 3:27 am
Posts: 48
Hello,

i have examined these error a little bit more and found, that it only occurs if use a MappedSuperclass, two entities inheriting from these MappedSuperclass and both entities are linked to eachother via m:n relation. And then you need your PostUpdateListener, which touches the collections of the entities...

Have opened a jira-Issue http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763

You can vote for it ;-)

Hope, this will be fixed soon...


Last edited by Rhodan on Mon Aug 06, 2007 5:14 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2007 7:39 am 
Beginner
Beginner

Joined: Mon Sep 12, 2005 3:27 am
Posts: 48
while further testing i noticed, that it isn't necessary to inherit from an abstract @MappedSuperclass to reproduce the failure. This simply means:

two entities + m:n relation + PostUpdateListener = AssertionFailure !


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 27, 2008 12:46 pm 
Newbie

Joined: Tue Feb 21, 2006 12:22 pm
Posts: 16
The problem is that AbstractFlushingEventListener.performExecutions() can result in new CollectionEntrys being created (because listeners access lazy collections, etc...). These CollectionEntry objects are technically created during a flush but not when the PersistenceConext.flushing attribute is set.

I looks safe to update AbstractFlushingEventListener.performExecutions() to:

session.getPersistenceContext().setFlushing(true);
try {
session.getJDBCContext().getConnectionManager().flushBeginning();
// we need to lock the collection caches before
// executing entity inserts/updates in order to
// account for bidi associations
session.getActionQueue().prepareActions();
session.getActionQueue().executeActions();
}
catch (HibernateException he) {
log.error("Could not synchronize database state with session", he);
throw he;
}
finally {
session.getPersistenceContext().setFlushing(false);
session.getJDBCContext().getConnectionManager().flushEnding();
}

That should get rid of this issue, but I am have not analyzed everything that occurs in session.getActionQueue().executeActions() so there could be some side affect, but since the 'flushing' attribute is really only used for CollectionEntry objects, it seems safe.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.