All,

I have been reading the forums for any information I can find on using NHibernate in a remoting context. It seems that everyones approach to this problem is to use a stateless service classes (BLL) with a static session factory. Each method in the serivce class then opens a new session and closes it at the end. What I am curious about (and have not found in my readings) is how does this affect performance during an update operation? My guess is NHibernate will have to requery the table for said object just to figure out if it has even changed. Could anyone please expand on this?

Assuming the above, I was wondering if anyone would care to share an alternate solution to the problem. My thoughts are to create client activated objects with a very short lifetime (<30 seconds). Most pages render in well less than 30 seconds, so it should not be a problem. This method would allow you to keep the session around through out the request, but on the application server instead of the web server. Would this solution make the problem better or worse? Can an existing session re-attach to a disconnected entity that it served up?

Any other help or suggestions are appreciated on this topic.

Thanks,
Chris

NHibernate doesn't requery the row (unless you enable select-before-update); it directly updates it... (most of the time faster)

To attache a detached entity to an opened session, use:


But I don't understand what you are suggesting.

I'm new to ORM tools such as NHibernate. I like the idea, and the fact that I don't have to write anymore SQL statements (I hate databases). I also like the idea of not using DataSets, since most of the time they end up containing small amounts of data not suited to their use. However, not knowing much about how these tools are used, I don't want to end up with a performance problem at the end of the project. This leaves me with the problem of what to do with the session object. I assume for performance reasons, its better to keep it around the duration of the page request, so I was looking for a solution that could accomplish this, but allow me to distribute the Service layer (BLL). The solution I suggested in the second paragraph was more me thinking out loud (bad habit). I realized later that it was probably not ideal since I would like to at some point serve up some webservices. This lead to more digging, and I did discover one thread that suggested that the overhead of creating a session was ~40ms. Well thats not to bad, and I am slowly coming to grips with the fact that solutions that save you time tend to add overhead (hopefully not too much though).

The one problem that I see at the moment is if I would like to use the methods of two different services in the same transaction. Having a session per request made this easy to handle, but I guess I face this all the time with traditional DataSet based solutions. I read once that .Net 2.0 answers this problem, but that will have to wait.

I'm still open to other suggestions about how to use NHibernate in a remoting context, but think I will progress down the session per method route for now.

Thanks NHibernate for the hard work!

Chris

codeslam,
We have come up with a solution for the problem of your kind. In short, let me describe the solution to you. I dont know if that will help you. But $0.02 thoughts...

<thoughts>

First query the database for the required data. This might also include childrens too. (For my case, I have explicitly set lazy="false" since I need to display all children in the same screen).

Next, I have created a ValueObject from the hibernate classes. Each layer in my application if defined in such a way as to use only appropriate objects. The entity objects (here the poco hibernate objects) will never be used in the presentation tier.

Basically, the ValueObject is a map that stores the values queried from the database. When this data is updated in the ui, I update the ValueObject in the front end. Since the ValueObject already has the value obtained form the backend, I use that for checking interimmediate values.

Of course, this mechanism would not work if the data is being updated by may users. In my case, it is not so.

Besides, I am next planning to send only the updated values to the back-end. This way, I could also minimise the data flow between different layers and also the network traffic will be reduced.

I have written a util method to convert this ValueObject into its appropriate entity using reflection. This object is then sent to the database layer to do updates to the db,

In short, only my business layer and the data access layer of my application ever knows about the hibernating entity. Rest of the world only sees that as a ValueObject.

Note: Here the ValueObject is more like a transfer object. It is **NOT** the representation of a value object as described by Martin Fowler.

</thoughts>

Annother point to note:
The current application that I am writing is for Windows Forms. It can also be very easily adopted for a web application.

Thanks for the reply, but I would rather avoid the extra step and the cost of more reflection (Nhibernate is already using reflection to load the objects). I'll just have to define service methods, that will call other services behind the seens to handle these instances. Its probably more efficient anyway, since it will reduce the number of trips to the application server.

Thanks,
Chris