Hi,

I am trying to manage an object graph with organisations and organisational units (OU). An organisation has a list of OUs and a OU has a list of child-OUs as well. So, we have a tree that looks like:

OU
.|
.|- OU1
.|- OU2
.......|
.......|- OU2.1

All those OUs are in the list of OUs of the organisation. From Organisation to OU we have the CascadeType.All and from OU to childOUs it's CascadeType.All as well.

Now we are trying to manipulate that tree on the client. Therefore we load the organisation and all the OUs in a session and close the session at the end. On the client we add the OU "OU2.2" as a child of OU2 which means something like OU2.add(OU2.2) AND organisation.add(OU2.2).
Afterwards we do a hibernateTemplate.update(organisation) which leads to an NonUniqueObjectException.

What we found out so far:

The session.update(organisation) leads to a cascading update of the OUs.

The NonUniqueObjectException is thrown when the OU2 is to be updated as it is already bound to the session.

It looks like it has something to do with the fact that the OU2.2 is referenced by two different objects (organisation and OU2) which are both changed and therefore both updated. But when the OU2 is updated via the cascading update it is already bound to the session.

What do we have to do to solve the problem?
Do we have to call hibernateTemplate.merge(organisation) instead of update? This looks a little weird as we want to update the organisation and we know that there is no organisation in the session at that moment.
Or do we have to remove the cascades from organisation to OU? The looks even weirder as the OUs have to be deleted when an organisation is deleted for example.

I read a lot in this forum and googled for a while, but it seems that most of the people who had this problem were using the wrong identifier, but that is no my problem.

Any hints would be greatly appreciated. Thanks in advance,
Ole

PS: Interesting side note: the problem appears on a IBM Websphere Application Server 7, but NOT on a Tomcat 5.5. I would have betted that this problem has nothing to do with your application server, but we have tried it several times with exactly the same WAR and its always the same result.