[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Geoffrey De Smet commented on HHH-2763: --------------------------------------- I have this bug even without using a m:n relation: My class A which validates using a property of its ManyToOne lazy relation to class B (which happen to have a OneToMany relation whichs breaks): class A { private B b; // ManyToOne @AssertTrue public boolean checkProps{ return prop1 == getB().getProp2(); } } The above probably works, unless B has a OneToMany lazy collection prop3. I merge in a detached A a with a non-lazy detached b (which has a lazy prop3), a becomes persistent, b becomes lazy. During validation b becomes initialized (with prop3 lazy), but apparently too late as b's prop3 throws the above AssertionFailure. The only workaround I see is using validation on the service layer instead of the hibernate layer, but our current architecture doesn't permit that. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Venkat Shanmugam commented on HHH-2763: --------------------------------------- I dig into the issue and realized flushing attribute may be the problem. So, I set flushing to true and false before and after calling executions respectively. public void onPostInsert(PostInsertEvent event) { try{ event.getSession().getPersistenceContext().setFlushing(true); Iterator iter = listeners.iterator(); while( iter.hasNext() ){ ICUDListener icud = (ICUDListener) iter.next(); icud.execute(event, ..........); } }finally{ event.getSession().getPersistenceContext().setFlushing(false); } } I appreciate any insight on this workaround. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Ally Bongo commented on HHH-2763: --------------------------------- I'm getting this issue as well. I've updated the code in CollectionEntry to specifically check for the name of the collection I'm using, and ignoring postFlush if that's the case. The collection I'm dealing with is immutable. The loadedPersister has a mutability check available to it. Would only performing the postFlush() on mutable collections be an option ie can you saftly ignore immutable collections in this process? eg include the first line: if( loadedPersister != null || loadedPersister.isMutable(){ if ( isIgnore() ) { ignore = false; } else if ( !isProcessed() ) { throw new AssertionFailure( "collection [" + collection.getRole() + "] was not processed by flush()" ); } } -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Christophe updated HHH-2763: ---------------------------- Attachment: cdel_analyse.txt Attachement to comment of cdel on Oct 19 2007 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] 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 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Adrian Pillinger commented on HHH-2763: --------------------------------------- How close is this to completion? We have exactly the same error and it prevents us auditing changes to our data. Thanks. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Adrian Pillinger commented on HHH-2763: --------------------------------------- My work around for this is to set the processed flag to true on all collections in the current persistence context within the listener. Since my listener is in the post insert/update/delete phase I hope that all collections have been processed correctly by now. Having said this, hibernate looks as though it will warn me about any side effect. I've looked at the hibernate code and the method Collections.prepareCollectionForUpdate(...) checks for collections being processed twice. Therefore if I set processed to true and it has not been processed yet hibernate will throw an exception. My code to set the processed flag to true is as follows... /** * Marks all collection entries in the current persistence context as processed * * @param session The current session */ private void markCollectionsAsProcessed(final Session session) { if (session instanceof SessionImplementor) { SessionImplementor sessionImpl = (SessionImplementor)session; final PersistenceContext persistenceContext = sessionImpl.getPersistenceContext(); final Map collectionEntries = persistenceContext.getCollectionEntries(); final Collection values = collectionEntries.values(); for (Object obj : values) { CollectionEntry ce = (CollectionEntry)obj; ce.setProcessed(true); } } } -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Michael Newcomb commented on HHH-2763: -------------------------------------- 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. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Denis VERGNES commented on HHH-2763: ------------------------------------ I have also this issue using Compass 2.0.0 with Hibernate 3.2.6. A workaround is to remove lazy loading on your many-to-one relationship. It worked for me. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Martin Backhaus commented on HHH-2763: -------------------------------------- This problem i got too. My conclusion was, that you have not to change the state of the current object in the current session within events. But if you want only use changed attributes - use the findDirty() (ore something called like this) to touch only changed (and loaded) attributes. Iterate over dirty fields within the same session works fine for me. But i have to read in some cases all data -> i used another session. If you would like to use another session, you should do the work within onPreUpdate() (not post), to fetch old data. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Darren Bell commented on HHH-2763: ---------------------------------- We'd like a resolution to this one. We've put a VERY horrible kludge in place to work around this, but it's very ugly and time consuming. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Gail Badner commented on HHH-2763: ---------------------------------- Initializing a collection is not supported while the session is being flushed. This would be difflicult to fix. As Martin Backhaus mentioned above, the listener could use a different session to initialize the collection. He has provided a workaround in HHH-3317 that should also work here. I realize this is an important issue and I plan to document the workaround and add it to the test suite. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Eike Hirsch commented on HHH-2763: ---------------------------------- Gail, did you document the workaround already? Can you provide a link? -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Eike Hirsch commented on HHH-2763: ---------------------------------- Just for the record: Envers is suffering from this bug as well. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole reassigned HHH-2763: ----------------------------------- Assignee: Steve Ebersole -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Geoffrey De Smet commented on HHH-2763: --------------------------------------- That's a pretty annoying no-no :) What kind of solution would you recommend for this @AssertTrue? @AssertTrue public boolean validateMomIsFemale() { if (getMom() == null) { return true; } return getMom().getSex() == Sex.FEMALE; } I suppose something like @AssertTrue public boolean validateMomIsFemale() { if (getMom() == null || !HibernateSpecificClassInMyDomainModel.isInitialized(getMom()) { return true; } return getMom().getSex() == Sex.FEMALE; } That HibernateSpecificClassInMyDomainModel is hibernate implementation detail creeping in my otherwise blissfully hibernate-unaware, jpa annoted domain classes? -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Geoffrey De Smet commented on HHH-2763: --------------------------------------- AssertTrue is a hibernate-validator 3.3.x annotation. Emmanuel talked on Dzone about the validation standardization and stated "Bean Validation should never go and traverse a lazy association and trigger the load of the association by side effect. That would be a very bad behavior. So, JPA has a way to put some limits in the object graph. The Bean Validation will actually validate." So he's probably aware of the problems like this that AssertTrue causes. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Tim Stavenger commented on HHH-2763: ------------------------------------ @Steve I am encountering this same error; however, I have no custom listeners and am therefore not (willingly) iterating or initializing collections in a listener. We're only using the listeners that Hibernate 3.3.1.GA executes by default, so if Hibernate is doing this, it would lead me to believe that it is an error in Hibernate? I've found that the change Michael Newcomb proposed on 27/Mar/08 11:20 AM (see his comment above) resolves my issue, but I don't know the impact of the change. It is in a class that appears you authored, so you may know? Michael proposes changing org.hibernate.event.def.AbstractFlushingEventListener#performExecutions(EventSource) to include setFlushing() calls: protected void performExecutions(EventSource session) throws HibernateException { log.trace("executing flush"); session.getPersistenceContext().setFlushing(true); // *************** new line 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); // ************** new line session.getJDBCContext().getConnectionManager().flushEnding(); } } -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] benoit heinrich commented on HHH-2763: -------------------------------------- Hi all, I know this problem is there now for a very long time, but today has been my turn to play with it, and after struggling a long day on it, I went to a solution that seems quiet generic and work very well for me. The idea is that when you use an hibernate event, if you try accessing a lazy collection, then the CollectionEntry corresponding to the lazily loaded collection get added to the PersistenceContext and hibernate crashes when it finds those entries because they are neither processed, neither ignored. After thinking a bit of the problem, and reading a lot in the different bug reports, I came to a conclusion that if the entries are not yet processed (because really, they're not) then maybe we could process them later on, after the flush() is done. Still, on the same idea, I looked deep in the hibernate code, and I've created a new FlushEventListener that replace the default one (EJB3FlushEventListener because I'm running in a jboss app server) and I'm simply removing the CollectionEntry that are considered invalid from the PersistenceContext during the postFlush(), and then, once the postFlush() is done, I'm adding these entries again into the PersistenceContext and I'm flushing again. The way this automatic "flush() again" is implemented allows the user to have multiple events generated by other events as much as you want (that's a lie, there is a limit of 100 right now) and it'll automatically "flush() again" every time it's needed, and this is all transparent to the code. I've attached the class, so if you want to try it feel free to use it. If you have any comment concerning the way I've implemented that workaround, then feel free to either send me an email, or reply to this bug, and make sure that you vote for it, so one day we get it fixed properly by the hibernate team ;) Cheers, /Benoit -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Julien Dubois commented on HHH-2763: ------------------------------------ Grails provide a workaround for this issue: http://github.com/grails/grails-core/blob/master/src/java/org/codehaus/gr... This workaround solved my specific issue (using Envers), and doesn't seem to have any side effect (I'll post another comment if I find a side effect later). It's also quite close to Benoit's solution. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Brian J. Sayatovic commented on HHH-2763: ----------------------------------------- I'm on a .NET project using NHibernate 3.0.0-GA (a port of Hibernate 3) which exhibited the same bug. We applied the same patch concept from Grails' PatchedDefaultFlushEventListener to our project and, at first glance, it has solved this bug. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole updated HHH-2763: -------------------------------- Issue Type: Sub-task (was: New Feature) Parent: HHH-6071 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole updated HHH-2763: -------------------------------- Fix Version/s: (was: 4.0.0.Alpha3) 4.1.0 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] j nadler commented on HHH-2763: ------------------------------- Agreed Stevo - it's past time this gets resolved. Or they could just close the Jira if they have no intention of ever resolving. It certainly sounds that way from some of the commments made by Hibernate team members. enerally the number of votes, watchers, comments, and workarounds on an issue like this should be a red flag to the team that something is really wrong. If all these people are simply confused about how to use Hibernate, why is that? Perhaps there's a damn good reason we're all trying to do this... -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Farrukh Najmi commented on HHH-2763: ------------------------------------ All of a sudden I have run into this bug. It reliably manifests itself when I have a certain object M that is a member of a Collection attribute of a parent object P being persisted. If I take that object M out of the collection the bug goes away eve if there are other similar members in the collection attribute. IMHO, this is a bizarre and serious bug that needs urgent fixing. My scenario is quite complex to provide a reproducable test case but I will be glad to work with a developer to help debug the issue. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Rock commented on HHH-2763: --------------------------- thanks 'benoit heinrich' for the workaround. It works for me. I registered the listener in persistence.xml: {code:xml} <persistence ...> <persistence-unit ...> ... <properties> ... <property name="hibernate.ejb.event.flush" value="com.vocado.services.hibernate.HibernateWorkaroundHH2763" /> </properties> </persistence-unit> </persistence> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole updated HHH-2763: -------------------------------- Fix Version/s: (was: 4.1.0) 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole resolved HHH-2763. --------------------------------- Resolution: Fixed Fix Version/s: (was: 5.0.0) 4.0.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] j nadler commented on HHH-2763: ------------------------------- Big thanks Steve. This is incredibly helpful. I've got lots of listeners that need this, and some hacky workarounds I will be able to remove when 4.0.1 ships. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763?page=c... ] Steve Ebersole closed HHH-2763. ------------------------------- Prepping 4.0.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira