7:20 a.m.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c...
]
Christophe commented on HHH-2763:
---------------------------------
We have similar problems with other relation patterns. I've analysed the attached
original TestCase (m:n relation, see testcase.zip) and came to these suggestions
which may solve the problem (background and details can be found in the attached file
analyse_of_cdel.txt):
- (Solution 1) Class CollectionEntry: set a default value for flag processed (see
####Comment 0.0)
- Method StatefulPersistenceContext.addUninitializedCollection: one of these two points
is sufficient to solve our problem
-> (Solution 2) flag flushing has value false and we are in a flushing action: if
this is
a bug and if this bug is corrected, then the our bug is solved
-> (Solution 3) flag processed could be set to true at this place because we are
sure the collection
was just read from the DB
- (Solution 4) Constructor CollectionEntry (For collections just loaded from the
database) (see ####Comment 26.2)
Evaluation:
Side effects for Solution 1 are difficult to evaluate: it affects all clients of the
CollectionEntry class
whose logic may be built on the asumption that the field has a false default value.
Such a change affects CollectionEntry Items (i.e scope is limited).
Side effects for Solution 2 are difficult to evaluate and are beyond the Collection
scope.
Solution 3 has the lowest side effect potential but with the risk that collections
that are loaded in another way will still cause our bug.
Solution 4: constuctor is also called by
StatefulPersistenceContext.addInitializedCollection.
Fixing here may have an undesired side effect.
(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: 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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira