Problems when accessing lists through property

Description

Hi,

When refreshing an object the following exception is thrown:

NHibernate.LazyInitializationException : failed to lazily initialize a collection, no session or session was closed

A test case is attached that demonstrates the problem.

We are struggling to determine exactly what the problem is. The class can load from the database, but cannot refresh.

This appears to be because during refresh the first mapped list is only partially loaded when added to the property. Subsequent lists are fully loaded when added to the parent object. This means we cannot call any logic on the object when it is being set to the property (for validation or setup), which is a serious problem for us.

Note: this bug appears whether we have lazy loading turned on or off. We are running off the trunk.

We can provide further details, or assist in any investigation.

Regards,
Dave

Environment

None

Attachments

2

Activity

Show:

DavidP June 10, 2009 at 10:05 PM

Thanks Fabio,

We have tested this on our systems and the Refresh function behaved as we would expect it to.

I added and removed items to the collections after the load and before the refresh, as well as updated property values to see if refresh reloaded the objects from the db. It did in all cases.

It is confirmed that the collections are all loaded on refresh, even when lazy loading is enabled, the property setter can still access the Count on the object, the tests pass and I think that satisfies our requirement.

Cheers,
Dave

Fabio Maulo June 5, 2009 at 6:00 AM

This is the comment of Refresh method:
It is unadvisable to use this to implement long-running sessions that span many business tasks. This method is, however, useful in certain special circumstances.

You are using Refresh to reattach a detached entity where Refresh was implemented only for some special case and only for attached entities.
In practice, in your case, you should use a Get<T>.

Btw I'll take a look to check what happening and understand if we can support Refresh even for detached entities.

DavidP December 16, 2008 at 2:00 PM

Hi Fabio,

We are trying to cancel changes made to the domain. We need to refresh from the last saved state in the database and then rollback the state to the one in the database.

So we wish to refresh(), then transaction.rollback(). However, we can't get past the refresh() when there are collections assigned in the way we have shown.

Here is the use case:

  • user makes changes which are reflected in the domain objects

  • user decides not to commit the changes (decides to cancel changes, or decides to revert because they are unable to get a write lock, etc.)

  • user wishes to revert changes to domain objects (not reload, because the object graph is quite large)

Does that help explain the use case?

Cheers,
Dave

Fabio Maulo December 16, 2008 at 5:57 AM

I still don't understand why you need to do that...
Why you need to change the fresh state loaded from db...
Really can't understand the use-case.
I can understand that you need to change something that don't become from DB but really I can't understand your case.

DavidP December 15, 2008 at 10:08 PM

Hi Fabio,

We are retrofitting our existing system to use nHibernate. Our existing system contains examples of this kind of arrangement. Our existing system updates state variables when new properties are assigned.

We have modified the test case so there is an additional test case. The additional test case demonstrates an exception with one list that is not lazy loaded. Note that when there are multiple lists, the second and third list can access the Count property without it failing. We have also changed the original test so that nothing is lazy-loaded.

We are confused about how we should use the where clause. We don't think adding a where clause would solve the problem in the case where there is one list.

Regards,
Dave

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Who's Looking?

Open Who's Looking?
Created December 8, 2008 at 9:33 PM
Updated July 22, 2009 at 7:21 AM
Resolved June 5, 2009 at 6:51 AM
Who's Looking?