If I delete an entity and then flush the session, if the entity is referred to anywhere else in the session cache, I get



The code that's doing the delete doesn't know anything about the specific type of the entity being deleted, and there can be a lot of stuff in the session cache, so it would be major pain to somehow search through the session cache for other entities that refer to the one being deleted and clear the references (using Reflection?). Is it even possible to walk through the session cache like that?

I guess I could resort to requiring every entity to implement an interface defining a write-once "IsDeleted" property and a "Deleted" event. All entities with properties referencing other entities would have to subscribe/unsubscribe to the event when a referenced instance is associated/dissociated. An implementation of IInterceptor.OnDelete() could then set the IsDeleted property on the entity being deleted (if it implements the interface), and the deleted entity would then raise its event. Then the referring entities, listening to the event, could clear their references to the deleted object, freeing the deleted entity or any other code from that responsibility. Still sounds like a hassle though.

Does anyone else have this problem? Is it because my sessions live too long and have too much stuff in them (i.e. the "solution" is to always have sessions so short-lived and sparse that any code using them should know exactly what's in the cache?)

IMO, whenever you have to delete an entity, you should find all associations/collections refering/containing the deleted entity and remove it
(this probably imply changing the way you use sessions...)

I have seen this occur when I do not remove an object from it's parent collection.

To give an example. Object OrderLine has a reference to Order, and Order has a collection of OrderLine's. If I want to delete an OrderLine, I have to remove it from the Order.OrderLine collection.

I have solved this with a design decission. I have a Save function on my DAL and I override this function for any objects that I need to perform this patern on. So in my case there is a generic Save(object obj) and a Save(OrderLine ord) that first removed the OrderLine from the Order.

Like the original poster we have complex business logic on our server involving many objects. We encounter this issue periodically and it is sort of helpful; it indicates a real bug where we are saving inconsistent objects some of which have an item marked for deletion and other(s) which reference the deleted object.

The problem is that it is hard to tell which association is holding the non-deleted object, and which association caused the cascade delete.

Does anyone have tricks or tips for figuring this out?