Hello,

i'm using NHibernate in our webapplication. But it brings some extra problems and i don't realy know how to fix them in a proper way.

For editing large BO's i store the BO in de asp.net session, so i don't have to load the object every page reload. But i close the nhibernate session.
When i try to store de BO later on, i get an error.

Is there a way to update object that are not retreaved van de current session?

An other question i have is, does every isession has its onw database connection? Or pools nhibernate the connections every request? If it does, ik kan store the ISession in the asp.net session to.

Can someone give me an answer to my questions?

The best solution is to re-attach the BO to a new session at the next request with ISession.Lock() and LockMode.None. This only has to be done when you want to persist the BO or make lazy loading work.

This may not be the best place to bring this up, but... It seems like there is a little bit of confusion to be found in the docs / forums about how one reconnects an entity object to a new ISession. Some places recommend Lock() with LockMode.None, and other places call for SaveOrUpdate(). As nearly as I can tell, one should use the Lock() method only if you can be absolutely sure that the entity object in question has not been modified since it was detached, and that the database representation of that object has also not been changed (i.e. it's not stale). But how can you be sure of that, in an environment with even a little concurrency? That doesn't seem like a safe assumption to make, so I've been using SaveOrUpdate() pretty much all the time. Am I confused?

You mean SaveOfUpdateCopy.

SaveOrUpdate gives me the following exception:
a different object with the same identifier value was already associated with the session.
SaveOfUpdateCopy works "fine".

I have a question about reattaching the object to the session with SaveOrUpdateCopy: won't this end up persisting the modifications done to the object on the next flush of the session ?

Here is an example of what I'm trying to figure out:

I get an object (a user) from the database that I want to modify in a web form that spans multiple page/does postbacks. The user object has multiple collections (roles for example) that are all lazy-loaded for performance reasons. The user is "detached" because I want to update the information only when clicking the save button (which can occur after multiple postbacks/change of pages)... therefore the object is put into Session state or is serialized into ViewState.

Now, how can I be attached to a session and persist the information only when I want to ?

In the case I described, if I first detach the object to work deconnected from the session then I don't have access to any of the lazy-loaded collections (which is required)...
If I keep the object connected with the session, the modifications will be saved at the end of each session (which is not what I want)
If I ever call a SaveOrUpdateCopy, the modifications will be persisted when I may not be yet ready to do so...

Therefore, I'm trying to find a solution that is transparent, where an object that is put into Session state keeping all the advantages of lazy-loading but gets persisted only when I decide to.

Thanks for the help !

Actually that's a great question that I've been looking for a good answer to for some time.

I've worked around the problem by making sure all my classes have an implicit interface 'SaveRequested' which is a boolean and have implemented an Interceptor which checks SaveRequested in the FindDirty method.

If SaveRequested == true then the FindDirty returns null (the default behaviour) and if SaveRequested == false FindDirty returns an empty array (which will cause the object to be considered not dirty and so it will not be saved.) In this scenario I set the SaveRequested to true if I want the object saved and everything else will be ignored during a flush.

I don't know if this is a good solution, but it was the best I could come up with. I think it has some implications if you want to persist changes to objects in a child collection, but I'm not sure as I've elected to prevent that in my framework and haven't done adequate testing to prove it one way or another.

If anyone else out there has any better suggestions I'd be happy to hear them!

Cheers,

Symon.

I think what you need to do is set FlushMode.Never. This ensures that the object has lazy loading capabilities but it will not be updated. I found this mode to be desireable for performance issues when the object you're accessing is for reading purposes.

When you decide to save the object (save button) call SaveOrUpdateCopy (or Update??)

Hope this helps