views:

70

answers:

2

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

I came across a situation where a user edited an object so it's in their first level cache in the ISession. Another user then edited the same object.

At this point User1 still sees their original version of their edits where as 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 a 2nd level cache enabled. For NHibernate Long Session should I just disable the first level cache entirely?

Edit: Adding some more terminology to what I'm looking to achieve from 10.4.1. Long session with automatic versioning the end of this section concludes with

As the ISession is also the (mandatory) first-level cache and contains all loaded objects, we can propably use this strategy only for a few request/response cycles. This is indeed recommended, as the ISession will soon also have stale data.

I'm not sure what kind of documentation this is for it to include both probably and then immediately say the session will have stale data (which is what I'm seeing). What's the solution to this right here or is there none?

+3  A: 
Mauricio Scheffer
Added information in regards to your link to optimistic concurrency control.
Chris Marisic
+3  A: 

Just use IStatelessSession instead of ISession.

Also keep in mind that NH wasn't designed to be used with long-living ISessions (as already mentioned by others). One problem is that you already mentioned. The other is that the performance drops significantly when there's a large object graph tracked by NH. Both problems could be avoided by using IStatelesSession. It gives you detached objects not being tracked by NH.

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

Also remember that a session is a wrapper over IDbConnection. Keeping it open can easily lead to conneciton pool starvation.

Filip Zawada
Does the IStateless use the 2nd level cache? I can't seem to find any definitive answer from google.
Chris Marisic
But if I'm using IStateless it's pointless to even manage session at all.
Chris Marisic
Stateless session doesn't interact with any second-level cache.
Filip Zawada
Well managing sessions (as in your scenario) doesn't have much sense for me whatever the case. You can use regular or statless session, close it when get request ends, then when user posts a form, you copy values from post request to object fetched with newly opened session (not stateless) first checking if the DB version (optimistic control) is not higher than the one passed from form.
Filip Zawada
I want the long running session pattern to be able to correctly handle wizard interfaces so if a user abandons their wizard it just destroys the data instead of leaving half completed data in my database. So yes I do correctly need the 1st level cache. Which my implementation handles fine, it's when 2 users have different versions of the same object in their first level cache it breaks down. This really seems like a shortcoming of NHibernate that there should be an option for ISessions to use 1st level cache only for transient objects and to disable it for non-transient.
Chris Marisic