Hi all,

We are working with NHibernate, focussed supporting multiple databases.
I need to handle NHibernate session throughout my application.

1) Maintaning session throughout the application - By enabling Lazy = true.
2) By handling the session wherever required for data operations.

When I tried my application in both the scenarios, I could not notice much difference in performance. It takes same time in loading the application and in fetching data.

Suggest me which approach can be followed and any performance issues with either of the cases.

Currently I am using Sql2005 and Oracle10g for trial.

Thanks for your time and consideration.

Cheers
Sudhagar.S

Hello,

Throughout the forums, you'll notice 3 main approaches for the management of the session in a winforms application:
a) keeping 1 session open for the whole application
b) having 1 session per form
c) having 1 session for each atomic piece of data access

I do not think (a) is a good idea. In fact, it really is a very bad idea because everything you loaded during your applications' lifetime, stays in the session. This boils down to a huge memory leak. The only advantage is that you don't have to care about lazy-loading.

A lot of people seem to like the 1 session per form approach, and also seem to be satisfied with it. I can emphasize with that, but this approach means you are binding the lifetime of your session to a forms' lifetime (suppose you're building a 3-tier application, how can you manage that ?).
Also, if objects are passed from one form to another, you'll have to rebind you object to another session anyway.

Personally, I think approach (c) is the way to go. Of course, I do realize that it is a pain in the ass to manage the lazy loading this way, but on the other hand it allows you to freely pass objects from one session to another and to have a stateless application server without having to keep track of which session was used to retrieve which object.

So it boils down to this: what kind of application are you building? For a middlesized application, I think approach (b) can be handy because you don't have too much hassle with the lazy loading. For an entreprise-grade application, I'm thinking approach (c) would be the best.

Unfortunately, there aren't many examples of approach (c) to find, so I'm building in my spare time an example of a 3-tier application using remoting, that I will post here somewhere in the next week. It won't be a beauty, but it might help.

I don't have much experience with WinForm apps; despite of that, I tend to agree with xasp.

Approach (c) is not unlike how one would handle the session in a webapp, where you don't really have the luxury of keeping and reusing the same session.

In both approach (a) and (b), you would need to disconnect the session anyway because you do not want to keep hanging on to the connection while you are waiting for the user. That means you will have to manage the status of the session in any case; in other words, you can't really get away with not having to deal with laziness with approach (a) and (b).

Good luck.

xasp ,

i wanna thank you for that good news, about your demo...

Hello,

In the application I'm working on, I have to load many complex objects all the time, and I'm using 1 session opened for the whole application (case (a) described by xasp).

As the session (1st-level) cache contains a lof of data, it takes a lot of time when I need to save/update 1 object, because NHibernate reads every object to check if it has been updated.

As it's a BIG application, I don't think it's possible to use 1 session/form (especially as it's a 3-tier application) or 1 session for each atomic piece of data access (because I don't see a clean and simple way to do that).

To solve my problem, I have the following idea :

1) Keep the single session opened for the whole application, but keep it as a "read" session, i.e. it will not be used to save, update or delete. I'll have to manage carefully the content of session cache.

2) Create 1 "write" session each time I need to save/update/delete. I'm already working in "commit" flush mode, and I'm always calling SaveOrUpdate or Delete each time I need to create/update/delete an object.

Do you think it's a good idea, or am I missing something important here ?

Thanks in advance for your feedback,
Mikvix

Hello,

I think you'll have a huge memory leak if you do it the way you describe, because all the objects you retrieve will be kept in het 1ste level cache of your session : imagine turning on 2nd level cache for all your classes, this would yield the same result.
Unless you manually evict() on regular basis a lot of objects in your application-wide session.

As you pointed out yourself, you will have to be very careful managing the session cache of your application-wide session because you might very well end up with a lot of objects in that session that are no longer in sync with the database.

I must admit I'm a little puzzled about the fact that on the one hand you say you have a 3-tier application and on the other hand you can have an application-wide session. I'm not sure how to visualize that (but this is beside the point).

Anyway, you asked for an opinion, and this is mine: I do not think an application-wide session is a good idea. I understand the approach of one-session-per-atomic-piece-of-data-access is troublesome, but I do believe it is the best way especially if you're writing a big application.

Thanks a lot for your feedback xasp !

I'll look at the solution you posted on another topic.

(Regarding the 3-tier architecture, it was a mistake. It's 2-tier)