Hi,

I have a child collection that is populated dynamically based on user input in the UI but not persisted to the DB until the user requests a save. So, instead of saving to the DB, the transient collection is stored in the cache and regenerated as required.

The reason for this is that repeated user input on the UI forces this collection to be updated frequently and having it persisted in the DB all the time kills performance.

The child objects have a rich connection to other domain objects and which have lazy loading enabled in places and I am getting a LazyInitializationException when I attempt to navigate a collection that has not been loaded yet.

Is it possible to reconnect the collection to a current session so that lazy loading will work?

Thanks,

Jason

Yes,
you can try : session.Lock(entity,LockMode.None);
then the entity's collections/subentities should load.

I tried that but it throws an exception because the objects are transient.

The cascade settings determine if any related objects are also reconnected. I think you'll need cascade="all" for automatic reconnecting. If you can't work with this cascade setting, you'll have to reconnect the object graph manually. Not nice, but it can be done.

I could probably use cascade="all" and then just clear the collection before I save the parent.

How would I go about manually reconnecting the graph? Also, is this something that I should even be considering or is it bad NH practice?

Dunno, at the time we didn't yet use the NH second level cache in Cuyahoga, we manually reconnected the cached object graph on each request and that worked out pretty well. At least, the performance was top notch. Still, it felt a little bit dirty because quite some infrastructure code was leaking into the app.

Just to clarify - do I manually reconnect the graph using the Lock() method?

While going through your object graph, you'll have to know yourself if the each detached entity is transient or persistent, and if persistent, if it was changed or not while detached. Then you'll have to do the following:

* If transient, call session.Save()
* If persistent and not changed while detached, call session.Lock()
* If persistent and changed while detached, call session.Update()

Still, if a persistent entity was not changed while detached but one of its collection properties had items added or removed while detached, you'll still need to call Update() rather than Lock().

Doing all this manually is a major pain, but I don't know of any other way if you don't have everything cascading ...

Excellent...thanks.

For reasons I won't go into here, we recently had to change our cascade policy from "all" to just "delete". Now collections apparently aren't getting reattached when we call session.Lock(entity) on an uninitialized proxy (or an entity with an uninitialized collection)

How do you manually reattach collections if you can't use cascade="all"? Why does the cascade setting even matter here?

In WrapVisitor.cs, I see this code in ProcessCollection():


Is this what we have to do? Seems awkward, having to hook up both ways, and more verbose than necessary ...

Nevermind. I had also just tried changing my calls to session.Lock() to session.Refresh(), but it looks like Refresh() doesn't actually reattach, so we need to lock first and then refresh.

In any case, although the collection attachment methods I pointed out above are public, they are effectively internal since you need to pass the session as the implementation type, not the interface type.

Actually, I am getting

when I try to initialize an uninitialized collection after reattaching its (already initialized) owner via


From what I understand, this should not happen once the owner is reattached to a session. What am I doing wrong?

Aaaargh, it turned out I was trying to initialize an old copy of the collection that I had grabbed before calling session.Lock() and session.Refresh() on the collection owner. The collection instance itself is reassigned to the owner by Refresh(), so I have to make sure I get the collection instance after calling Refresh() on the owner ... (sigh)