Duplicate objects in OneToMany relationship

[dsouza]

I'm having trouble with the following OneToMany relationship:

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
@JoinTable(name = "PRDCT_GRP_TO_FILTER",
 joinColumns = { @JoinColumn(name = "PRDCT_GRP_ID") },
 inverseJoinColumns = @JoinColumn(name = "PRDCT_CLASS_FILTER_ID"))
public Collection<ProductClassFilter> getClassFilters() {
 return classFilters;
}

It seems that whenever I call getClassFilters() it returns a collection with twice as many objects as there should be. It actually duplicates every single object in the relationship so instead of returning an array of, say, 2 objects, it returns 4 objects (2 of which are duplicated).
I've tried using @JoinColumn instead of @JoinTable, I've tried playing with cascade types, fetch types and I've checked and rechecked the data in the database (which is correct).
It works fine when I persist the data but after I fetch it, everything is duplicated. If I try to merge it afterwards, it tries to save the duplicated objects so I get a unique constraint exception from oracle, but not from the framework.
Any ideas of what might be causing this?

[dsouza]

Forgot to say I'm using EJB 3 RC5 and Jboss 4.0.3 SP1.

[tom_goring]

I also have this problem.
It seems to be an issue for me when I have more than 1 OneToMany relationship. Or when the child also has a OneToMany relationship.

I'm using alpha 5 embedded jboss libraries

[ejb3workshop]

I am also having this problem, so I started using SET's. It seems to be a bug/feature in hibernate.Take a look at this thread which explains it in more detail.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76796

Alex
ejb3workshop.com

[dsouza]

Thanks, that thread was very enlightening.
I understand how annotating relationships as EAGER can be really bad sometimes, however IMHO it is impossible to foresee every scenario a developer will run into and impossible to be sure that he will never, ever, have a reson to use it, thus EAGER relationships, even if nested in other EAGER relationships should work as advertised. In this case some overhead would be necessary to get the framework to show the expected behavior but it's a small price to pay.
I don't mean to criticize the great work being done in EJB/Hibernate and I DO think things should be implemented in the most efficient way, but the time lost in trying to figure out what is going on and then explaining it to others could have been used in more productive things.
If a developer has certain performance needs than he should do his homework about best practices and enable/disable whatever options are necessary. The default gain in performance and the obligation to use what is supposed to be the best practice should not come at the expense of odd framework behavior, even in rare cases.
Anyway that's just my opinion. In the end I did work around the problem by changing the said relationships to LAZY and making some other adjustments in my code. Sorry if I sound bitter, I know it's still in beta and all... it's just some frustration for the time I invested in trying to make things work.