Unit Of Work Module - Correctly handle Unit Of Work in web scenarios
This is actually implemented as a custom
) rather than a Http module. In order to add Unit Of Work functionality to your Web application you must add a Global.aspx page to your Web application project specifying that it inherits from
. Typically your Global.aspx file should contain the follow:
<%@ Application Inherits="Rhino.Commons.HttpModules.UnitOfWorkApplication" Language="C#" %>
implements the Open-Session-In-View pattern
and extends this to support Long Conversations
Is a simplistic solution to the problem that can occur when rendering the view (the controls on the aspx page for example) where the NHibernate session has already closed. In this scenario when the view is being rendered, navigating Persistent class associations (eg aCustomer.OrderAt(3)) can trigger a lazy load that then throws a lazy load exception because the NHiberante ISession is already closed.
solves this problem by ensuring that the ISession remains open while the view is being rendered and will only be closed (and disposed) just before the response is sent to the web browser. Unlike some implementations of this pattern, an ADO transaction is not
started and committed for each Page request. In fact the treatment of database transactions is orthogonal to this pattern implementation and must be implemented separately.
Open-Session-In-View is the default pattern when wiring up the
to the Http pipeline for your Web application. The extension to this pattern to support Long conversations will require you adding code to your Web application to make calls to the
to delineate the start and end of these conversations. Please note that the choice between Open-Session-In-View and Long conversations is not mutually exclusive within your Web application.
For example, you may decide that one particular series of page request-responses should be modelled as a single Long conversation so you add the necessary calls to
within these pages. All other page request-responses for your site will follow the Open-Session-In-View pattern.
In short, a Long conversation keeps the Unit of Work open between multiple page request-responses by persisting the Unit of Work into the
Long conversation is also known as a Long transaction or a Business transaction. A Long conversation deals with the idea that a business transaction will often span multiple page request-responses. Take for example, an online Auction website where an administrator may request a page to show the details of an Auction with the intent of reviewing these details before approval. This administrator approves the auction based on the information that is displayed. From the point of view of the administrator, a business transaction started from the moment that he viewed the details and finished when he submitted the request for approval. In order to honour the ACID properties of a transaction our web application must perform a concurrency control check to ensure that the details of that Auction did not change during the time when the administrator was reviewing its details to hitting the approve button. One way of ensuring this concurrency control check is performed is to keep the Unit of Work that loaded the Auction alive between page requests and signalling within our Web application when the Unit of Work should be flushed to the database and then closed. When the changes to the Auction are flushed to the database, NHiberante will automatically perform the necessary optimistic concurrency control check for us (note: this assumes that the mapping for the Auction class includes the necessary version element).
To delineate these long conversations in a Web application use you must call
. Again database transactions must be implemented separately.
Sequence diagram for Open-Session-In-View
Sequence diagrams for Long conversations
Start of Long conversation
End of Long conversation