Hibernate version:
1.2.0 beta 1

I am getting LazyInitializationException errors under the following combination of conditions:
- I am accessing an uninitialized proxy
- this proxy represents a property which is set to cascade="none"
- the root entity was detached, and then re-attached using Lock()

In stepping through the code, it seems that Lock() successfully reattaches the root entity, and cascades down through the object graph for all properties which are... well, set to CASCADE :-p

However, this means that any non-cascaded properties, which have uninitialized proxies, will not be associated with the new active session, and thus will not be usable (throwing the above exception).

I understand this behaviour - after all, if we made changes to these non-cascaded properties, and flushed the session, we would inadvertanly write the changes to the database, against the cascading rules specified.

But how does one sovle this problem? I have googled for several days with no suggestions found. Please please please don't think this is another "lazy loading after session closed" issue. Though I am new, i think i've done the due diligence in reading documentation, searching, and trying the accepted patters for this kind of thing.

So in closing, can anyone confirm this behaviour, and has anyone come up with a solution... (i.e. "you HAVE to initialize lazy non-cascaded properties")?

Thank you so much for reading this far, and any help you may offer.


Full stack trace of any exception that occurs:
Could not initialize proxy - the owning Session was closed.

at NHibernate.Proxy.LazyInitializer.Initialize() in C:\Development\cpbinc\NHibernate-1.2.0.beta1\nhibernate\src\NHibernate\Proxy\LazyInitializer.cs:line 81
at NHibernate.Proxy.LazyInitializer.GetImplementation() in C:\Development\cpbinc\NHibernate-1.2.0.beta1\nhibernate\src\NHibernate\Proxy\LazyInitializer.cs:line 240
at NHibernate.Proxy.CastleLazyInitializer.Intercept(IInvocation invocation, Object[] args) in C:\Development\cpbinc\NHibernate-1.2.0.beta1\nhibernate\src\NHibernate\Proxy\CastleLazyInitializer.cs:line 59
at CProxyTypeAddresscommon_INHibernateProxy_ISerializable2.Equals(Object obj)
at DFWHC.GroupOne.GoRes.business.common.applicant.ApplicantAddress.Equals(Object obj) in C:\Development\dfw_hospital\GroupOne\GoRes\library\business\common\applicant\ApplicantAddress.cs:line 34
at DFWHC.GroupOne.GoRes.business.common.applicant.ApplicantAddress.get_IsPrimary() in C:\Development\dfw_hospital\GroupOne\GoRes\library\business\common\applicant\ApplicantAddress.cs:line 65

Yes, you have to reattach those objects manually.

Thanks for replying Sergey.

When re-attaching a detached entity, is there any way to mimic the behaviour observed when an entity is loaded originally (i.e. using session.Get())?

Specifically, where non-cascaded properties are attached, but not checked for dirty status (and thus non persisted) whent he session is flushed?

Thank you,

-Sasha Borodin

My rather 'brute force' solution to this problem may not be much of a solution at all. But, if practical, I load the parent object using 'get' (ie instead of Lock) using a new reference. Creating a new, fresh parent object with no old child objects lying around (from a previous peristence context).

Performance might suffer (negligible in my case) but the code is simple and works...

What are the chances of changing NHibernate to just 'handle' this situation without an exception?

Is it feasible/desirable?

I'm often reconnecting sessions with objects that were retrieved from other sessions. Such that operating on this object works sometimes and not other times, depending on whether you had any proxy's initialised or not (which is pretty much impossible or very difficult to work out beforehand).