views:

559

answers:

2

Cleaning up some transactional logic and wondered how other people were handling it.

Ayende's recommendation seems to be to handle transactions at the service boundary. This is a ASP.NET web app though, so it hasn't got a clear cut service boundary, at least not right now.

What do people do?

  • Create a single transaction per request in a HttpModule and handle commit on EndRequest, rollback on Error?
  • Create transactions in the actual "services" in the application and handle it multiple places?
  • Something else?
A: 

Most people use a session-per-request strategy as stated in your first bullet point. However, I don't believe that the transaction needs to be committed on EndRequest. In many web pages it would be easier to commit the transaction based on user action (e.g. clicking submit) and let EndRequest just handle disposing the ISession.

As far as I can tell, there's no need to create an HttpModule as the same functionality can be created in global.asax: http://forum.hibernate.org/viewtopic.php?t=993041.

Jamie Ide
+1  A: 

You can use a IoC Container for your service layer and the container can manage the transaction and the Nibenrate Session.

Your WebApp Controller => call (A) Service Layer => call (B) one or several DAO methods /operations.

The IoC container like Spring.NET will manage te TX scope, by example at (A) and will provide a Session to your DAO in (B). The commit (or rollback) will be handled at the end of the service layer call.

Matthieu