Based on the topic "Using NHibernate with ASP.Net" (http://wiki.nhibernate.org/display/NH/Using+NHibernate+with+ASP.Net) I have implemented NHibernate session management by opening a session when an HttpRequest begins and closing it when this request ends. My question is how should I do transaction management within the scope of this request. Here are two approaches I can think of:

1) Begin a transation when the HttpRequest begins (right after the session is opened) and commit the transaction when the HttpRequest ends. The advantage of this approach is that begin and commit transactions are tucked away in framework code and developers do not have to deal with it explicitly. However, it is difficult to rollback when an exception occurs because the transaction is not accessible to application code.

2) Second approach is to let the application code do transaction management. Disadvantage is that now transaction begin and commit become the responsibility of application programmer. However the advantage is that in case of an exception, doing a rollback is very easy because the transaction is easily available to the application code.

Any opnions on these two approaches? Are there other approaches that people have tried?

Thanks

You definitely don't want to open a transaction when you create your session at the beginning of the request. Actually there's no point in even open the session at the beginning of the request. You could do this on demand. When you start a transaction, a transaction will be opened on the database, so I think this would not be good to have open for your whole request.

I like to have transaction management done at the application layer. Note that this is not the UI layer. You appplication layer will act as a facade for your domain layer. If you arent exposing NHibernate out of your data layer then you can wrap the NHibernate transaction with an Adapter.

Actually I am creating my Session on demand, I managed to drop that detail in my original post :-). I understand your point about controlling the transaction in the application layer (our team calls it the service layer which sits on top of the data access layer). So that's how we are doing it now.

Anyway, I was looking at the Spring Framework on the Java side. They somehow manage to completely tuck away the transaction management code in the framework. Thus even the application (service) layer does not have to bother with it. If an exception is thrown, the transaction is automatically rolled back. Is there a possibility to do something like that on the .NET side? I hear that .NET has a way of doing declarative transactions. Can that be somehow used here to eliminate transaction management from application level code?

Well, there's Spring.NET, and then there's the Castle Project. Both have transaction management tools, AFAIK. You can read from the Castle creator's blog about his opinion of Spring. :D

this may be a naive suggestion, but can we derive our nhybernate classes from enterpriseServices and mark the classes as [transaction.required] and the transactional methods as [autocomplete()]?

-Manish

jnapier: why do you think opening the transaction at the request level is bad??

. I was under the impression that doing session-per-request is a good thing so doing the transaction at that level should be natural to...