I am trying to work out a robust way to remove a child entity from all collections on entity delete to ensure all related collection cache nodes in 2nd level cache are properly evicted. In doing so I came up with a solution below, which I hope someone can validate (please see specific questions at the bottom). But first, let me motivate the problem with a use case:

Let's say we have an entity that belongs to two collections:



Let's say the same Child 'c' belongs to a Mom and a Dad. On Session.delete(mom), Child c will be deleted by cascade (as orphan). 2nd level Collection node Mom.children will be evicted, but Dad.children will NOT be. To make sure Dad.children collection is evicted, one has to call dad.removeChild(c) during the same Session as session.delete(mom). Since Mom may also be deleted via cascade (say from another parent class GrandMa), it becomes cumbersome to keep track of places where one has to explicitly dissociate a Child from a Mom and a Dad. So I wanted to define how to delete a Child in one place, and ensure that method is invoked whenever a Child is being deleted - regardless of whether delete is explicit or by cascade:



Now define how to delete a Child:



To ensure MultiparentEntity.onDelete() is called whenever such entity is about to be deleted, I extend DefaultDeleteEventListener:



Questions
That's it. However, having implemented the above in several entities on our domain model I am seeing some errors - constraint violation attempts and possible failures to cascade (if, for example, 'mom' is being deleted by cascade) that make me wonder whether the above approach is sound. Is it ok to access and modify a (previously uninstantiated) collection from within a DeleteEventListener? In the above case we would end up instantiating and modifying Dad.children. Also, since 'dad' is being modified inside onDelete() an update Cascade from Dad to children should fire. WIll it? Finally, in above scenario, DELETE would cascade from Mom to Child, but UPDATE would cascade from Dad to the same child (latter as result of onDelete() call)> Would both cascade actions be fired, or will UPDATE be somehow discarded, given that there is a DELETE. Seems like UPDATE cascade could cause a Validator failure (on non-null) if fired before DELETE.

If the above is a misuse of the Event System, how would you solve the original problem of deleting a Child cleanly (including via Cascade)? thanks!

-nikita

Stack:
Hibernate 3.3.1.GA
Hibernate Annotations 3.4.0.GA
JBC3 as 2nd level cache

Seems like the above is either an anti-pattern or a valid pattern triggering a bug: if Child.onDelete() removes a different entity from another collection, that collection's cascade does not execute.

Say, for example Dad has another collection of Photo's and a method to find photos by child:



and we'd like to ensure that all photos of child are deleted when child is deleted (yes, sounds morbid, sorry). So, we'd amend Child.onDelete():



Dad.photos cascade DELETE_ORPHAN isn't honored when onDelete is called from DeleteEventListener (described above). If explicit delete(p) isn't added, I see a Nullability exception complaining about Photo.dad being null. Why is that?