Below is the pseudo flow for my web page when in edit mode

1. The web form would load the domain object via the business layer. (NHibernate's session was already discarded in the data access layer.)
2. Populate web form's controls with data from the object
3. User makes change to data, then click Update
4. Create the domain object and populate the object with data from the web form's controls
5. Use the business layer to save the object. The data access layer would create a new session.

I run into 2 problems in this scenario

1. For example, say there are 10 columns in the table, but only 7 columns need to be edited, I would only populate the form with the 7 data elements. When update, I would only fill the object with the 7 data elements available on the form. After the update, the other 3 columns now got wiped out.

2. On table that uses NHibernate versioning, NHibernate would throw an exception reporting that data has been changed by other users.

Please correct me if I'm wrong ... but base on my observations, I concluded that although some columns are not meant to be updated by the user, such as the version column, I still need to cache them somewhere in order to fill the object with them later when sending the object back for update.

If that is true, please advise and share with me your best practice. Do you cache the original object to the http session, or some other means?

Thanks very much in advance.

Check out Billy McCafferty's article at http://www.codeproject.com/aspnet/NHibernateBestPractices.asp. A best practice for using NHibernate with ASP.NET apps is called 'session-per-request', where each HttpRequest would have one session and all activity done during that time would be subject to what is called 'transparent-write-behind'...What this means is that edits done on entities during the session (Request) are synched to the DB when the Session is flushed at the end of the HttpRequest.
THis is transactionally sound since you aren't hitting the DB multiple times with all the user actions. Check out Hibernate in Action for details of this as well.
I use something similar using IoC but isn't less tied to an HttpModule.

Thanks for the article mnichols.

But in my situation, the edit is not in the same session (HTTPRequest). First session (HTTPRequest) is for populating data onto the page. User then makes changes, then clicks Save, which now requires a new session (HTTPRequest).

I come up with 2 solutions

1. When data is populated onto the page, cache the entity object in the HTTPSession. When user clicks Save, the page would retrieve the cached entity, and sync its values with data on the page, then save.

2. When user clicks Save, the page would reload the entity again via NHibernate, then sync the newly loaded entity with data on the page, then save it. But this is inefficient, as you have to make a select then a save, that is 2 calls to the database.

I don't mind either approach, as long as it's what most people do, so that I know I'm not totally off the mark.

I got most of the NHibernate concept, except for this one.

Your thoughts and advices are greatly appreciated.

I understand this dilemma. It depends on the objects you are loading in. Typically, if I am bringing in entities that have alot of relationships that aren't lazy (a deep object graph), then I'll cache the object (probably not the second-level NHib cache) in maybe a Session wrapper or some other storage until I want to post the values.
If the object really isn't that extensive, tho, it might just be best to reload and save on each roundtrip. That avoids stale data and other issues as well as being simpler.
Personally, I prefer using DTO's so I can work with lightweight objects in session until I need to post the hydrated entities they represent back to the DB. I've like this pattern ths far.
MIKE

Thanks Mike. I got it now.