How to negotiate long NHibernate session data?

Question

I have NHibernate sessions cached in an ASP.NET session.

I came across a situation where the user edited the object so that it was in the first level cache in ISession. Then another user edited the same object.

At this point, User1 still sees its original version of its changes, when User2 sees the correct state of the object?

What is the correct way to handle this without manually calling session.Refresh (myObj) explicitly for every single object all the time?

I also have second level cache enabled. For NHibernate Long Session, should I completely disable first level cache?

Edit: Adding another terminology to what I expect from 10.4.1. A long session with automatic versioning ends at the end of this section.

Since ISession is also a (mandatory) first level cache and contains all loaded objects, we can use this strategy for only a few request / response cycles. This is really recommended, since ISession will also have outdated data soon.

I’m not sure what kind of documentation it is to include both, and immediately say that the session will have outdated data (this is what I see). What is the solution for this right here or not?

Answer 1

This seems to be a well-known flaw of NHibernate, as described in the documentation provided in my question.

Answer 2

• You cannot disable first level cache.
• Check the Optimistic concurrency control in NHibernate docs.
• Also look at NHibernate.Burrow for long conversations.

Answer 3

Just use IStatelessSession instead of ISession.

Also keep in mind that NH was not intended for use with long-lived ISessions (as others have already mentioned). One of the problems is what you already mentioned. Another is that performance is significantly reduced when a large array of objects is monitored by NH. Both problems could be avoided using IStatelesSession. This gives you deleted objects that are not tracked by NH.

Not sure about the reasoning behind conducting sessions in an ASP.NET session. Maybe you could provide some details?

Also remember that a session is a wrapper by IDbConnection. Saving it can easily lead to the starvation of the pool.