NHibernate Pitfalls: Stateless Sessions

This is part of a series of posts about NHibernate Pitfalls. See the entire collection here.

Stateless sessions are a good thing: they offer a simplified API for performing updates, deletes and inserts, which does not require that the entities are known by the session beforehand and they can also offer some performance benefits. However, this comes at a cost.

It happens that stateless sessions do not support some of NHibernate’s features that we’ve become accustomed to:

  • Interceptors: no way to use them;
  • Events: never fired;
  • Cascades: never happen;
  • Dirty checking: not performed;
  • Second-level cache: not used;
  • Lazy loading: not supported.

So, if you need any of these, don’t use stateless sessions.

Bookmark and Share

                             

2 Comments

  • Could you remind me where the setting is that could allow me to know whether stateless sessions are being used or not in a project? Now that you brought forward those limitations, I'm gonna want to check whether this is used or not when discovering a code base I'm not familiar with.

  • Stateless sessions must be opened explicitly: look for OpenStatelessSession() method of ISessionFactory.

Comments have been disabled for this content.