NHibernate Forge
The official new home for the NHibernate community

Some basic concepts about one strategy to manage the NHibernate session

Article
Comments (0)
History (2)
100% of people found this useful

Some basic concepts about one strategy to manage the NHibernate session

Filed under: , [Edit Tags]

Some basic concepts about one strategy to manage the NHibernate session

This is just a strategy!


Frequently, we are asked how we should manage the session of NHibernate (referred to as "session"). When should we open the session? When should we close the session? How many sessions should we have open?.

I will tell what I often do to manage the sessions. Other strategies are possible for Other targets, These strategies will be subject of other wikis.

Introduction

Let’s review some of its funcionalities before asking how we should manage the session:
1. The session manages the persistence of our entities then the session has information about the state of the objects at certain times (when the objects were loaded)
2. The session has a cache, it allows a single instance of each object that we load within it. When we try to get an object which has already been loaded, the session returns us a reference to the same instance of the class.
3. The lazy loading will use the session to get the objects only when they are requested.

Then...

If we accept the introduction is true then we may say:
A. Each object should be loaded and saved in the same session (reason 1).
B. The related objects should be loaded in the same session (reason 1 and 2).
C. the objects with lazy loading should have the same session (opened) at the time to load the lazy information (reason 2 and 3) unless we use an eager fetching strategy. If we disregard it then we can have an Exception of type LazyLoadingException with the message "no session" or "session was closed" because we just did it, we closed the session ahead of time.
D. When an object is modified, it is modified again on the session because it is the same! (reason 2) the changes aren't visible for other sessions until we do a Flush and Commit of the transaction. Only after that, the changes are visible to other sessions. This behavior is the key to know how many sessions are necessary.
E. The session should be closed when we don't need the same instance of it (reason 1 and 2, considering A, B and C)

To Conclude

When should I open the session?
Before loading (or saving) the first object from objects linked.

When
can I close the session?
I can close the session when I don't use any more objects loaded (or saved) with the session.

Depending on the life time
The life time of the session should contain the life times of the objects loaded or saved with it.

Who can manage the sessions for us?

  • Rhino, Spring, Castle, Burrow.
  • The Contexts of NHibernate.
  • Other AppBlocks will be launched.

Other tips:

  • When the session throws an exception, we shouldn't use it any more.
  • You shouldn't take the session only as a connection to database. You should not think Save or Update are equivalents to Insert and Update in the database
  • If you are managing correctly your sessions, then you shouldn't need to invoke the "Evict" and "Clear" methods deliberately.

Recent Comments

Leave the first comment for this page.
View All
Powered by Community Server (Commercial Edition), by Telligent Systems