Hibernate version: 1.2.0.GA

I am using the "Conversations with detached objects" pattern. I have entities A and B such that A has a collection of Bs. The underlying tables have a foreign key from B to A, and the collection is a bag mapped as inverse="true". My code is roughly like this:



When the code to create a new "b" is repeated, I get the exception "reassociated object has dirty collection" when I try to attach "a". Originally I did not update "a" since there is nothing on its underlying database row that has changed, but I added it thinking it would make NHibernate happy so it could mark the Bs collection not dirty. Unfortunately, I still get the exception.

Any idea what I'm doing wrong? BTW, A has other collections -- I'm not positive that it's even the Bs collection it's complaining about, but the exception message doesn't tell me which collection is dirty ...

I changed my reattachment approach from ISession.Lock(entity, LockMode.None) to ISession.Update(entity) and the problem went away.

I've seen more examples in documentation that use Lock() to reattach, and only a few examples that use Update(). Come to think of it, I'm not sure why you'd ever want to use Lock() rather than Update() to reattach entities ...

Hi Nels_P_Olsen!

I see message somewhere in this forum about this problem - it seems that cascade=delete-orphan is the source of troubles. But IMHO it will be much more inefficient to fall back to "manual" cascading of collection operations :(
I think you may have concurency issues with .Update() approach... If your entity will be modified or even deleted between you get it in first session and "update" (attach) in second.
I bet it will be better to find out the source of this problem (it is something related to collection snapshot that NHib made to track added/removed items) and try to fix it...

You can attach an entity to a session either through Lock or Update. They have different semantics though which you need to be aware of. The Lock approach is intended to attach an object that has not been updated, so that changes can be tracked by NHibernate and then reflected in the database when the session is flushed.

Conversely, Update is indended to be applied to a disconnected entity that has already been updated. The updates are immediately reflected back to the database. Note that the entity and all cascaded entities are updated regardless of whether they have been changed. If you would like only the entities that have been updated to have UPDATE statements executed for them, you need to leverage the select-before-update option. Note that this option is inefficient because all entities eligible to be updated are first SELECTed so NHibernate can compare and determine whether an UPDATE is necessary. This option should really only be used to prevent execution of UPDATE TRIGGERs or something like that.

So in conclusion, the issue you experienced is due to using the Lock strategy to attach an entity that has already been updated. Update is the appropriate strategy for your scenario.

Since we track dirty status on our entities ourselves, it's easy for us to know if a detached entity has been modified. Still, I tried doing something like



However, often when it tries to do a Refresh(), I get exceptions like "cannot modify a loading collection". I don't know if the same errors occur with plain-old Lock() instead of Refresh(), but it seems that if you're going to reattach a detached entity, you should make sure it's not stale.

For the time being, we're always doing Update(), and if an exception gets thrown, do a Get() and then manually, painstakingly merge in any dirty properties on the entity originally requested for reattachment, return the one from the session and expect the caller to deal with the fact that the instance "attached" is not the one passed ...