i think it's safe to assume that you have the "mappedBy" attribute set for the User side of the relationship, right?

the mappedBy attribute basically says which side of the relationship is responsible for maintaining the DB foreign key link. so, you could try this in your existing code:

User[] users = portal.getUsers();
for(User user : users)
{
 user.setPortal(null); //or user.removePortal(), whatever your method is
}

em.remove(portal);

first thing is that you only need the annotation on the get*() methods.

try setting the portal to null for each user before you actually remove the portal.

here's an example i just tested:

@Entity
public class Parent
{
 @Id
 @GeneratedValue
 private Long id;

 @OneToMany(mappedBy="parent", cascade=CascadeType.REMOVE)
 private Set<Child> children = new HashSet<Child>();

 public Set<Child> getChildren()
 {
 return children;
 }

 public void setChildren(Set<Child> children)
 {
 this.children=children;
 }

 public Long getId()
 {
 return id;
 }
}
==========================


@Entity
public class Child
{
 @Id
 @GeneratedValue
 private Long id;

 @ManyToOne
 private Parent parent;

 private String name;

 public Child(){}

 public Child(String name)
 {
 this.name = name;
 }
 ...
}

@Stateless
@Local(TesterLocal.class)
@LocalBinding(jndiBinding="session.Tester/local")
public class Tester implements TesterLocal
{
 @PersistenceContext(unitName="PU2")
 private EntityManager em;

 public void doWork()
 {
 Parent p = new Parent();
 em.persist(p);

 for(int i=0; i<5; ++i)
 {
 Child c = new Child("child-"+i);
 c.setParent(p);
 p.getChildren().add(c);

 em.persist(c);
 }
 em.flush();
 p = null;

 Parent pp = em.find(Parent.class, 1L); //i know the id is 1
 em.remove(pp);
 em.flush();
 }
}

So is it a fair statement to say that delete cascading does not and will not work on OneToMany relationships? How inconvenient.

We're using a stateful session bean (Seam) which allows us to keep changing the object model until the user is ready to either a) save or b) cancel. On a cancel its easy - we just walk away from everything. On a save, our goal was to simply end the conversation in the default manner, which has Hibernate flush all of the changes.

It sounds like we're going to have to keep track of the before/after state, descend through all of the OneToManys, to comparisons, and manually handle everything. It seems odd that CascadeType.REMOVE doesn't do this, since it certainly could follow the same logic - that's why I'm still hoping that we're missing some setting somewhere...?

the above post is a working example of cascading delete.