If I have a standard bi-directional parent child relationship (i.e. the parent has a "List<Child> getChildren()" method and the child has get/setParent() methods) what is the proper way to handle the setParent() calls. Should the caller know that it has to also fix the parent's collection? Or, should the child pojo call add/remove on the new/old parent internal to the setParent() method? Or, is there some trick to get the Parents to refresh?

The documentation primary seems to address this problem from the parent side (by noting that you also call Child.setParent() when messing with the Parent's collection). I more interested the reverse. For instance, when editing the child, there is a dropdown to select its parent. The UI code would simply call setParent() with the new value, but I can't figure out the best way to sync the parent's collection afterwards.

Any thoughts?

Hibernate version:
3.1.2

In all the apps I've written, I've always put this sort of thing in my DAL, which uses the factory pattern. So ChildFactory.newChild(Parent p) would call child.setParent and p.getChildren().add(newChild). You could also put it in business logic, but that leaves you open to errors of omission if you have to do it in more than one place.

It is reasonable to not expose the Child.setParent() method, and to have Parent.getChildren() return an immutable Collection. Then you would have your factory access those methods through the implementation class instead of the interface. This guarantees reasonable protection.

There are any number of options to deal with this. I recommend reading up on patterns of use in data access applications, as my suggestion here may not be suitable for you, especially if you haven't separated your DAL and your business logic very cleanly.