.net - What should be the lifetime of an NHibernate session?

Question

I'm new to NHibernate, and have seen some issues when closing sessions prematurely. I've solved this temporarily by reusing sessions instead of opening a session per transaction. However, I was under the impression that opening sessions each time you need them was the recommended approach for session lifetime management. No?

So; what is the recommended way of handling sessions? What should their lifetime be? One session pr transaction? One singleton session to handle everything? Or what?

Edit:

Note that my application architecture is a desktop application communicating with a server side service, which is what does all the Database handling, using NHibernate + Fluent. (If this makes any difference...)

Answer 1

You want a session management strategy that allows your app to function effectively and take advantage of the things that NHibernate gives you - most notably caching and lazy loading.

Creating sessions is an inexpensive process and requires little up-front RAM or CPU, so you shouldn't worry about conserving or re-using sessions (indeed, re-using them can lead to some nasty and un-anticipated side-effects). The session factory is the expensive thing and should be built once and only once at app startup.

The rule of thumb is this: the session lifetime needs to be long enough that you don't have persisted objects hanging around in scope after the session ends.

Once the session ends, all change tracking for objects you got from that session stops, so those changes don't get saved unless you deliberately re-attach that object to a new session. The session should therefore be around for as long as the objects you fetch from it are going to exist. In a Web app, that generally means a session for each request; in WinForms, a session for each form.

In your case, with a service (I assume it's running as a Windows service) doing the NHibernate work, you might wish to consider having a session created for each new request from the consuming desktop app, and disposing it when that request has been serviced. Not knowing exactly how your service runs and what mechanism the desktop app uses to talk to it (remoting? WCF? Plain old SOAP?) I can't really be more specific.

(There are some exceptions to this general rule - suppose you have a set of persisted objects that represent a shared resource to which other code will refer but not change, you can load these up-front at app-start and leave them disconnected from then on.)

If you find performance sluggish under such a strategy, it may be that you're just talking to the database too much and your object graph is complex; look at second-level caching in this case.