ASP.NET and NHibernate session

sebastijanp · **Joined:** Sun Jul 03, 2005 3:54 am **Posts:** 9

As I understand from all this readings of articles and blogs. In asp.net it is not correct to use:

Code:

[ThreadStatic] public static ISession mcurrentSession;

So in asp.net the following is equal:
I just create some IHttpModule and put an instance of my HibernateUtils (with: private ISession mcurrentSession) in HttpContext.Current.Items with:

Code:

private void Context_BeginRequest(object sender, EventArgs e)
{
HibernateUtils hu = new HibernateUtils();
HttpContext.Current.Items.Add("HibernateUtils", hu);
}

private void Context_EndRequest(object sender, EventArgs e)
{
if (HttpContext.Current.Items["HibernateUtils"] != null)
{
HibernateUtils hu = (HibernateUtils)HttpContext.Current.Items["HibernateUtils"];
hu.CloseSession();
}
}

And the get the SESSION in all classses (Dao and similar classes) during Request with a simple call:

Quote:

HibernateUtils utils = (HibernateUtils)HttpContext.Current.Items["HibernateUtils"];
IQuery q = utils.CurrentSession.CreateSQLQuery(...);

Is all this thinking correct?

Lp
Sebastijan

devonl · **Posted:** Mon Jul 04, 2005 7:43 pm

Well, in mh opinion, accessing the HttpContext object in your DAOs is not a good idea. If you do, then your DAOs are tied to the ASP model and what if you decide to port to another platform or create a WinFORMs app or something? It would be better to build your DAOs to accept a session during instantiation. Then it doesn't matter what mechanism you are using to manage the session, your DAO just uses the session that is passed to it:

Code:

public class myClassDAO : AbstractDAO {
  private ISession session;

  public myDAO(ISession nhSession) {
    this.session = nhSession
  }

  public FindStuff(MyClass myClass) {
    IQuery q = this.session.CreateSQLQuery(...);

    return q.List();
  }
}

Then in your ASP code you can do something like:

Code:

MyClassDAO db = new MyClassDAO((HibernateUtils)HttpContext.Current.Items["HibernateUtils"])

IList stuffCollection = db.FindStuff(myClass);

Again, this is just my own opinion.

-devon

baggins · **Joined:** Mon May 16, 2005 1:35 am **Posts:** 67

The reason commonly cited for not using Thread Local Storage in ASP.NET is concerns regarding thread pooling. That is, the thread that services one request is not guaranteed to service the next. However, from what I can tell, this is only an issue if the intent is to share the same session instance between requests. If a new session is created for each request and guaranteed to be cleaned up at the end, then in my opinion there should be no issue in using Thread Local Storage.

Perhaps a better choice is to use the System.Runtime.Remoting.Messaging.CallContext class instead of TLS. This is the class that is used internally by ASP.NET to store the HTTP context object anyway. This can apparently be verified by using Reflector to view the HttpContext implementation.

intesoft · **Posted:** Fri Jul 08, 2005 3:58 am

I developed this NHibernate.Helper project some time ago for use with ASP.NET. It may be something someone finds useful:

http://blogs.intesoft.net/simon/articles/16.aspx

The POCO classes I use have static methods for such things as GetById, GetList and so on which uses these helper clases but these could easily go in a separate layer. I like the way the code reads when they are used, eg:

Customer customer = Customer.GetById( 123 );

IList customers = Customer.GetListByRegion( "North" );

lamb.jim · **Joined:** Fri May 13, 2005 1:59 pm **Posts:** 11

Nice work, Simon. This is a much cleaner approach than the one used in Cuyahoga. I do break my data access code out into a separate assembly, but it follows the same naming convention. E.g.:

Objects.Person person = Access.Person.Get( 123 );

JackBigMac · **Joined:** Tue May 17, 2005 2:48 pm **Posts:** 47

intesoft wrote:

Customer customer = Customer.GetById( 123 );

And what does GetById look like? Something like this?

Code:

public void GetById(int Id)
{
  Db.Load(typeof(Customer), Id);
}

Just wondering...

Regards,
JackBigMac

Guest · **Posted:** Fri Sep 16, 2005 3:42 pm

Is the Simon helper project better then cuyahoga because all of the nhibernate specific's can be moved out of the WebUI.

Marcos Silva Pereira · **Posted:** Mon Oct 17, 2005 2:09 pm

Simon, this approach looks like ActiveRecord from Ruby. It's so much good if you could create a good query layer. I have tried implement something like this in Java using vargs, covariant return type and named queries. How do you implement your query layer? Have you implement crud (create, read, update, delete) operations using the same approach? Per instance:

Code:

Costumer costumer = Costumer.GetById(123);
costumer.name = "Simon";
costumer.update(); // HERE!

Kind regards,

Marcos Silva Pereira

k-dub · **Joined:** Thu May 12, 2005 8:45 am **Posts:** 226

This looks a lot like the ActiveRecord usage in MonoRail over at http://www.castleproject.org. Was any of the Castle code an inspiration, or is it just an inspired coincidence? I think it's an excellent way to solve this, but I'm a bit biased.

cil65 · **Posted:** Fri Nov 04, 2005 2:04 pm

I would like to write the same hibernateUtil class, using thread local storage, that is in Gavin King's book "Hibernate In Action" . Has somebody already ported it to c#. This looks like a realy clean way to deal with all the session crap and get hibernate config out of the webUI.

cil65 · **Posted:** Fri Nov 04, 2005 3:48 pm

Sorry, I should have read the sticky post about asp.net thread pool problem and not being able to use threadstatic.

I am leaning toward devon1 solution for my problem. This is because I want to have a webForms and winForms UI.

gekannt · **Posted:** Mon Nov 07, 2005 9:50 am

Ben Day's sample NHibernate app (http://blog.benday.com/archive/2005/10/02/2876.aspx) handles winforms vs. webforms access to the session in a way I like (from his NHibernateHttpModule class):

Code:

public static ISession CurrentSession 
{ 
   get 
   { 
      if (HttpContext.Current==null)
      {
         // running without an HttpContext (non-web mode)
         // the nhibernate session is a singleton in the app domain
         if (m_session!=null)
         {
            return m_session;
         }
         else
         {
            m_session = CreateSession(); 

            return m_session;
         }
      }
      else
      {
         // running inside of an HttpContext (web mode)
         // the nhibernate session is a singleton to the http request
         HttpContext currentContext = HttpContext.Current; 
      
         ISession session = currentContext.Items[KEY_NHIBERNATE_SESSION] as ISession; 

         if (session == null) 
         { 
            session = CreateSession(); 
            currentContext.Items[KEY_NHIBERNATE_SESSION] = session; 
         } 

         return session; 
      }
   } 
} 

Other classes just access this property to get the session, and they don't have to care whether they're running under winforms or webforms.

cil65 · **Posted:** Mon Nov 14, 2005 8:36 pm

Ben Day's has a good solution if you want to use WebForms and WinForms. The only thing I don't like is the nhibernate config's in the app.config and web.config. You should be able to put just one hibernate config in the data access project.

KPixel · **Posted:** Thu Nov 17, 2005 10:20 am

cil65 wrote:

Ben Day's has a good solution if you want to use WebForms and WinForms. The only thing I don't like is the nhibernate config's in the app.config and web.config. You should be able to put just one hibernate config in the data access project.

You can put it in an external xml file (like hibernate.cfg.xml)...

aarnott · **Joined:** Fri May 13, 2005 4:08 pm **Posts:** 64

baggins wrote:

The reason commonly cited for not using Thread Local Storage in ASP.NET is concerns regarding thread pooling. That is, the thread that services one request is not guaranteed to service the next. However, from what I can tell, this is only an issue if the intent is to share the same session instance between requests. If a new session is created for each request and guaranteed to be cleaned up at the end, then in my opinion there should be no issue in using Thread Local Storage.

Perhaps a better choice is to use the System.Runtime.Remoting.Messaging.CallContext class instead of TLS. This is the class that is used internally by ASP.NET to store the HTTP context object anyway. This can apparently be verified by using Reflector to view the HttpContext implementation.

ASP.NET 2.0 allows a single web request to switch threads, or for one thread to switch between requests before the first request is finished. If this is enabled you should never use TLS because your sessions will get mixed up.