Drawback of 'Maintain Bidirectional Relationship'

Question

I recently came to this understanding which changes the way we are trying to use TopLink. I thought I'd share it in an attempt to spare others some of the difficulties we've had, and also to elicit any further clarifications or corrections as necessary.
When you relate two domain objects with TopLink, the Mapping Workbench provides you with the option to Maintain Bidirectional Relationship. What this means is that, for example, if you have two classes Parent and Child, each with a relationship to each other, then all you have to do is call aParent.setChild(aChild) and you will also be able to retrieve the Parent object from the Child with a call to aChild.getParent(), even though you never explicitly called the Child object's setParent(Parent) method. TopLink updates the 'other end' of the relationship for you.
This sounds like a wonderful feature. However, it does have its drawbacks. Let's say that the Child has another Parent, we'll call them ParentOne and ParentTwo. Together, these Parents make up the Child's logical primary key, and so you've mapped these attributes of the Child in TopLink as its primary key attributes. You've also told TopLink to Maintain Birdirectional Relationships between ParentOne.children and Child.parentOne and between ParentTwo.children and Child.parentTwo. Now you've got a particular Child, aChild, owned by Parent instances aParentOne and aParentTwo. You want the Child to be deleted, so you remove it from both of its Parent collections. When you do this, TopLink also removes the references to the Parent objects from aChild, and now you've just altered aChild's primary key. If you selected this Child from the database, TopLink no longer recognizes your instance as the one you selected, and now you're going to have a really hard time deleting it. When you commit your UnitOfWork, you are likely to see an exception that says 'cannot insert null' into one of the LPK fields, or even an OptimisticLockException, as now TopLink is thoroughly confused about what the heck you're doing.
The moral is: Don't use Maintain Bidirectional Relationship on attributes that are part of a class' mapped primary key. And don't set that attribute to null if you want TopLink to continue to recognize the object. In the example above, something like the following would be appropriate:
Child>>
public void orphan(UnitOfWork uow) {
     boolean exists = uow.doesObjectExist(this);
     getParentOne().removeChild(this);
     getParentTwo().removeChild(this);
     if ( exists ) {
          uow.deleteObject(this);
     } else {
          uow.unregisterObject(this);
}Yes, you need to explicitly delete or unregister the object, even if you marked it as Privately Owned by its Parents. The fact that I'm doing the existence check before removing the Child from its Parents is just an extra precaution to make sure I do the test before I do anything that might change the LPK. Although this is probably useless, since, if I do modify the PK, TopLink won't be able to find the object again anyway.

Answer 1

I agree with John's conclusions and will be requesting enhancements to the mapping tools and documentation surrounding b-directional relationships involved in PKs.
One thing I do want to make clear is the original intention of bi-directional relationship support. This was added initially to support EJB 2 relationships. It was also added to the core product for use in some POJO frameworks. It has its uses and does simplify model development but has its trade-offs in addition to what John has posted. It requires indirection in both relationships and the relationship maintenance is only managed when in the context of a TopLink session the objects are read from.
I typically avoid using bi-directional relationship maintenance as the alternative solution of managing the relationships in the model are very straight forward. The result is typically better performing. Additionally, having a POJO model that is not dependent on the persistence manager allows this same model to be used in other contexts such as detachment through serialization.
Also, EJB 3 does not currently have bi-directional relationship management within the specification.
Doug