Move from JIIRA(HHH-419):

relating to FAQ:
-Hibernate throws: Flush during cascade is dangerous(117.html#A26)
-When I delete an object that belongs to a cached collection(117.html#A33)

This was discussed many times in forums and FAQ, but please have a look at my case.
Entity Parent has one-to-many(cascade<>none) with entity Child

parent=load();
child = parent.getChildren().get(0);
//other process...

//in another method or layer
delete(child); //throw ObjectDeletedException

Because delete(child) is called in a seperate method/layer, where developer does not know anything about entity parent,
so I cannot remove from set children to avoid this exception.
I think hibernate have enough metadata to remove child from set children automatically, developer doesn't have to care about this.

In fact, if hibernate do not support this feature, i have to give up cascading feature in my project.
(I love cascading feature so much!)

reply from Christian Bauer:

We obey normal Java semantics and will not break them. Use child.getParent().getChildren().remove(child) and ask in the forum next time.

Christian,
In the worst case, we have to load all children in order to delete 1 child.
Is there an api method to check whether a child is belong to a cached collection to avoid loading all children?

No, you don't, use a Bag. Welcome to the world of Java pointers.

And in case you want to continue this line of thought (and I'm sure you will exactly do that): There is no solution. Network programming languages, such as Java, are not suitable for data management. We do the best we can but we can only bend it so much. There is nothing Hibernate can do here.

Final statement: The problem has nothing to do with cascading/transitive operations, but only with reference counting/garbage collection, which is impossible (and thankfully unecessary) with a relational database.