[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()

[C. Delaloye (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

C. Delaloye updated HHH-2763:
-----------------------------

    Attachment: one-to-many_with_many_side_having_collections.gif
                bidirectional_many-to-many.gif
                HHH-2763_standalone_testcases.zip

In order to help the understanding of my previous comments, and I hope of the overall problem, I've prepared 
two testCases which reproduce / illustrate the problem.
The attached HHH-2763_standalone_testcases.zip contains a "standalone" (no need of an app. server) Eclipse Project with a JUnit TestCase that reproduces the problem for these two mapping patterns:

- testHibernateBugHHH2763Case1 (bidirectional many-to-many)
    this is the case initially described by the reporter
- testHibernateBugHHH2763Case2 (one-to-many with many side having collections):
    this is a concrete case which is perhaps what Geoffrey De Smet has met but (to my mind) confusingly 
    reported in it's comment of August 16th 

Please have a look at the attached files bidirectional_many-to-many.gif and one-to-many_with_many_side_having_collections.gif which give 
a graphical overview of the objects and relations.
These two cases uses a pre-update Listener which causes a Collection to be loaded during 
the flush phase and then lead to the "was no processed by flush()" exception. 

Entry point is Class: ch.rtc.infra.protok.client.InPro_ProtokHibernateEventListenerHibernateBugs_tc
Required to compile and run:
 - hibernate jars
 - junit.jar
 - commons-collections.jar, commons-lang.jar
 - hsqldb.jar

Another formulation of the bug would be:

the bug occurs when elements of a lazy collection (1) are loaded during a flush phase by a custom pre- or post- Event.
When these loaded elements (2) have mapped Collections (3), hibernate creates a CollectionEntry for each of them (them = mapped Collections). 
The problem is that these created CollectionEntries are instantiated with flag processed=false and they have no chance 
to have their "processed" flag set to true, as this only occurs in pre-flush phase and as this pre-flush phase is already done.
Consequently, the CollectionEntry.postflush() method which checks this "processed" flag will raise
the "was no processed by flush()" exception.

illustrated with Case2 (one-to-many with many side having collections):

(1) elements of a lazy collection: InPro_ParentWithLazyCollectionOfChildren.childrenWithCollections (many side)
(2) these loaded elements: instances of InPro_ChildWithCollections (many side)
(3) mapped Collections: collections defined on the many side: InPro_ChildWithCollections.collectionOfSimpleObjects  and InPro_ChildWithCollections.collectionOfValues
 Note that:
    - the problem is not dependent of the fact that the collection on the many side is lazy or not.
    - the problem also occurs if the many side has collections of values



> (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-2763
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.4.sp1, 3.2.5
>         Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3
>            Reporter: S.Schnabl
>            Priority: Critical
>         Attachments: bidirectional_many-to-many.gif, cdel_analyse.txt, HHH-2763_standalone_testcases.zip, one-to-many_with_many_side_having_collections.gif, Testcase.zip
>
>
> For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java.
> [Summarized]
> It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error:
> org.hibernate.AssertionFailure: collection [n-side] was not processed by flush()
> [Explanation]
> I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity.
> [Testcase]
> Both entities are linked with eachother (m:n). If i  now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush:
> Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] 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)
> ... 29 more
> Attention: EntityB.entitiesOfA is the other-side  collection of the m:n relation of the updated EntityA.
> We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes.
> Seems for me like a serious bug. Need this fixed asap ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira