I am writing a complex windows forms application with lots of ways to view and edit each domain object.
All of my domain objects implement INotifyPropertyChanged (ie, they all have a PropertyChanged event) so that when properties are changed, it is reflected in all the appropriate places.
My object model is selected from the database in lots of separate on-demand sessions (I don't want to load the entire thing on start-up as it is quite large).

To use the common Blog/BlogItem example, if I list all Blogs in one session, then all BlogItems in another session, BlogItem.Blog is never one of the objects loaded in the first list.


Both Logic methods above create and dispose their own sessions. Every line written to the console reads False.

I understand that this is perfectly normal behaviour (which is why I have overridden the Equals method on my objects). However my problem is if I register a PropertyChanged event in a Blog object loaded in the second session, then edit the equivalent object loaded in the first, the event obviously isn’t fired (since they are actually separate objects in memory).

What I really need is only one object instance created for any given primary key, no matter what session it is referenced in. I was hoping that the HashtableCacheProvider would achieve this, but nothing seemed to change when I switched it on (how would I tell if it is operating correctly?).
Is there a solution to my problem other than having a static property change registry (and hence adding another level of coupling between my domain and UI)?

I too am interested in knowing how to deal with this, as we have the exact same scenario -- lots of separate on-demand sessions, with entities implementing an interface with a PropertyChanged event. I thought the 2nd level cache was supposed to provide the desired behavior, but I've heard people have had trouble getting it to work.

No, second-level cache does not serve this purpose. Actually, NHibernate is just designed to work in a way where each session has its own copies of objects and objects are not shared between different sessions. Trying to coerce NH into sharing is going to be hard because you will essentially have to "fight" its underlying assumptions.

I understand that it's a bad idea to have multiple NHibernate sessions open at the same time, since any given entity can be associated with at most one session. However, since we hear so much about keeping NHibernate sessions short, and because many of us need to develop applications that can be heavily and arbitrarily customized by adding additional, isolated customization layers, it seems we have no choice but to always be creating and discarding NHibernate sessions for each little additional task that could possibly be executed. The entity objects then need to be constantly reassociated with new NHibernate sessions, via ISession.Lock() or ISession.SaveOrUpdateCopy().

Is this part of what you mean by "fighting" NHibernate's underlying assumptions? If so, how are we supposed to deal with the need to allow additional logic to be plugged into an application, at just about any point, where that logic may need to load additional entities (either explictly or through lazy-loading)?