Hello,

I'm doing the following: I have an AbstractAnswer class, with subclasses Answer and AnswerSet. An AnswerSet can contain objects of type AbstractAnswer, so I can build a tree structure with this.

The mappings are:
<class
name="de.rpf.customer.idg.mafo2.data.AbstractAnswer"
table="answers"
discriminator-value="abstract"
>
<id name="id" unsaved-value="0">
<generator class="native"/>
</id>
<discriminator column="class"/>
<many-to-one name="parentQuestion"/>
<many-to-one name="parentSet" column="setId"/>
<subclass name="de.rpf.customer.idg.mafo2.data.Answer" discriminator-value="answer">
</subclass>

<subclass name="de.rpf.customer.idg.mafo2.data.AnswerSet" discriminator-value="set">
<list
name="answers"
lazy="false"
cascade="all-delete-orphan"
>
<key column="setId"/>
<index column="listIndex"/>
<one-to-many class="de.rpf.customer.idg.mafo2.data.AbstractAnswer"/>
</list>
</subclass>
</class>
The ParentSet field in AbstractAnswer is a reference of type AnswerSet and may be null for the root AnswerSet.
When I create a new Answer and add it to the root AnswerSet it all works fine. Now when I create a new AnswerSet, set its parentSet attribute and then add it to the root AnswerSet, it should be saved during cascade. Instead I get this when I commit the transaction:

java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:445)
at java.util.AbstractList$Itr.next(AbstractList.java:418)
at net.sf.hibernate.collection.PersistentCollection$IteratorProxy.next(PersistentCollection.java:262)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:298)
at net.sf.hibernate.engine.Cascades.cascade(Cascades.java:341)
at net.sf.hibernate.impl.SessionImpl.preFlushEntities(SessionImpl.java:2285)
at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2015)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2004)
at net.sf.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:57)
...

I'm using Hibernate 2.0.3 on PostgreSQL 7.2.

I'm pretty sure I'm doing something wrong, but I can't find it. Any ideas?

Thanks
Carl-Eric

Addendum: The code used to do it looks like this:

AnswerSet rootSet = getRootSet();
new AnswerSet(rootSet.getParentQuestion(), rootSet);
t.commit();

The constructor looks like this:

AnswerSet(Question parentQ, AnswerSet parentS)
{
this.setParentQuestion(parentQ);
this.setParentSet(parentS);
}

The setParentSet method adds calls parentSet.addAnswer(this) to add itself to the parent AnswerSet. As far as I can see this *should* then be properly cascaded, so the new AnswerSet is saved.

The exception happens inside the t.commit().

Thanks
Carl-Eric

Ok, I think I've worked around this now.

I changed the mapping of parentSet in AbstractAnswer to have its own colum and not rely on the same column as the list in AnswerSet (it is now <many-to-one name="parentSet" column="parentSet"/>). I am now maintaining the link back to the parent AnswerSet "manually".

One question remains, though: What happened here? Was what I originally did really wrong? Is what I do now the correct way to do it? Or is there a more elegant way to handle this?

Thanks
Carl-Eric

I dunno, sounds like you did something "funny" in your Java code, like accessed the collection during the cascade. But I can't see any code, so I've no idea.

Well *that* can easily be changed :-)

Though I am quite certain I didn't do any funny things with it. I created the new set, committed the Transaction, and only then continued with my application. And I am 100% certain that there was no other thread doing anything with it either.

The code:


The constructor of AbstractAnswer simply sets the reference fields to parentSet and parentQuestion, and adds the Answer to parentSet, if necessary. That is all done by the time it gets to t.commit(), though.

With the AnswerSet list and the parentSet field sharing a column, the t.commit() call throws the exception mentioned in the original post. Now that they don't share that column any more it works.

It works now, so I am just interested in this out of curiosity, and to understand Hibernate better, because it does seem to me that it is just a workaround. If you think it's not worth investigating more, that's fine, though.

Thanks for your help, even though we users are a pain sometimes, Gavin ;-)

Carl-Eric

And do you implement Lifecycle or Interceptor, or do anything in a getter or setter?

Lifecycle and Interceptor: No.

Getter and setter... let me check... argh. I didn't see that. Mea culpa. Yes, I was modifying the parent AnswerSet in the setParentSet setter - I was simply adding the AbstractAnswer itself to the parent AS again (parent.addAnswer(this)). That it worked with my "workaround" was only due to the fact that for the workaround I also changed addAnswer to check whether the List contained this Answer already. Looking at it now, it seems that the original implementation was buggy in this regard anyway, since it doesn't make sense to always add the answer.

I didn't notice this because I didn't think Hibernate would call any of the setters during commit or cascade, so I didn't check the setters. I tried it again now with using the same column, and it works fine.

Sorry for bothering you, and thank you for your help.
Carl-Eric