I have been working with nHibernate for a few months now and think it has a lot going for it. I must admit I do not missing writing T-SQL at all. I still consider myself to be a novice at nHibernate best practices.

Let me describe what I'm working on...

Primarily an intranet web application, ASP.Net 1.1, SQL Server 2000 database, approx 200 tables, multi-tiered (MVC), roughly 200 full-time users, a few web services will be running off this also. You get the idea.

At the moment on my development workstation, while running and using the application, my ASPNET worker process will range from 120-150MB. Seems a bit high to me. I have not done any type of load testing on this application. I am concerned what is going to happen to my app server once 200 users start having their way with it.

On a separate, but related note - I am developing a small WinForms web crawler in my spare time. The process is very simple. I grab a page, check to see if it exists in the database, if not it adds the page content to a single table.

Meta code...

session.Clear();
IPage page = session.GetPageByUrl(url);

if(page==null)
session.StartNewTransaction(); //probably dont need to do this
//create new page and set properties
session.Update(page);
//if everything okay
transaction.Commit();

That's it. Everytime I want to process a new page I clear down the Session and either add a new Page to the database or do nothing. Pretty straightforward.

I ran this application overnight and in the morning I had processed 30,000 web pages - but my application gobbled up 1.4GB of RAM and threw an OutOfMemory exception.

This got me worried. I realised that nHibernate may not be the proper technology to do what I need it to do; probably could use a more direct SQL-based approach to get the data in the database. I can understand that.

However, I got a little concerned about the web application and how it is going to perform under pressure.

So, I guess the advice I'm looking for is:

Am I using the right technology? Or, am I being overly optimistic about nHibernate? Or, go back to sleep, you have nothing to worry about?

Any thoughts or opinions welcome.

Thank you

Ron

In general, check for these things:
a) you don't create more than one session factory in your application
b) you keep NHibernate sessions small and short-lived
c) you don't load more objects from the database than necessary. Use lazy loading for classes and associations and enable SQL logging to examine SQL that NHibernate generates.

Thanks Sergey,

Good guidelines.

With regards to our web application, do you forsee any difficulties? Can nHibernate stand up to that kind of challenge?

Cheers

Ron

Well, Java Hibernate handles this kind of applications just fine, so I suppose that the .NET version should too, but there may of course be some problems due to platform differences. You will need to profile your application yourself to see where bottlenecks are.

Every problem I've had with memory leaks in .NET came down to not disposing stuff. Any objects you create that implement IDisposable should have their Dispose() method called when you are done with them. When I am done with an NHibernate session, I dispose it after closing it.

If you have any classes that you're creating over and over that keep disposable objects, you may need to implement IDisposable in your class, and call Dispose() on your objects as soon as you're done with them. In your Dispose() method, dispose those objects it created (or, better yet, implement IContainer and add the disposable objects to the components field, and the Dispose() method snippet that Visual Studio generates for you will dispose all the objects in the components collection).

Oh yeah -- if you have disposable objects whose references are kept by mulitple other objects, those other objects keeping the references need to clear them when they're done (if the referencing objects live a long time or indefinitely), otherwise, the disposable object can never be garbage collected.