The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Question about where to store session for NHibernate

I really hope someone out there can help me with this becuase it's something I haven't worked with before and I want to do it correctly. I am working with NHibernate which relies heavily on session. Now, for each data object there is work with the current session. Where should I open -> close that session? On the page level? On the method level? On the application level? If on the application level where would I configure that? web config? app config? how?

I'm hearing rumblings that the best way to do this is WCF Windsor Integration.... anyone have an opinion on that?

Keep in mind that I am looking to make this a high traffic web app.... so I'm uncomf about using session in the first place.
Sara C Send private email
Thursday, August 14, 2008
Here is a multi year thread on that subject

If you are worried about performance because of the traffic level, I'd be more worried about NHibernate than about session.
Thursday, August 14, 2008
I think you would want your NHibernate session to be Request-scoped, i.e. at the Page level.  The NHibernate session is not related to and has no dependencies on the ASP.NET session so there shouldn't be any scalability concerns from that aspect.  I think Windsor would be a good choice, I believe it has some facilities for Nhibernate and the web.  I think Windsor can handle scoping it to the Request so that the first access to it on the page creates/opens it and flushes it at the end.
Thursday, August 14, 2008
I usually store my Unit of Work (which what an NHibernate ISession is) in the HttpContext.Current.Items collection (thought thats hidden as a generic data store).

This means your session is request scoped. Storing on a per thread basis is bad for as a thread can be reused.
Nigel Sampson Send private email
Thursday, August 14, 2008
+1 for session-per-request for Web apps.

It's superficially appealing to want to keep the session open for longer to get the benefits of first-level caching, but in my experience those aren't as big as you might think. If performance is really a major issue you can always turn on the second-level cache (if you can actually get it to work - timestamps are key here).

A lot of people get scared when they see that the Web server will be issuing DB calls for each request to each page in an app across x hundred users - but the DB is built to deal with heavy query load. You just need to scale out appropriately.

Keeping cached objects around in a read-only context, OTOH, is fine. If your system doesn't have to write changes to the DB (and many presentational Web sites are read-only in large areas) then a read-only session scope and some DIY caching / eager loading is very much your friend, performance-wise.
.NET Guy
Thursday, August 14, 2008
Thanks everyone. I agree on the per-request level, that's what I'm doing.
Sara C Send private email
Thursday, August 21, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz