Hi,

I have a small question regarding the "Open Session in View" pattern. What I understand is that we create a NH session in a httpmodule and begin the transaction and do a commt/rollback at the end of the request. This pattern make sure that the session is always available for the lazy loading to work.

My question is that the DB connection that was opened in the httpmodule (when I said _session.BegnTransaction()) will remain open throughout the period of the request. Is this not going to effect the scalability of the application as there will be as many open connections as the number of concurrent users.

What is happening is that in order to make the lazy loading work I am forced to make my transaction boundary longer (this also means that the connection will not be returned to the pool for the whole period)?

Is my understanding correct about this, or am I thinking wrong here?

Regards
Job Samuel.

You open the session in the HttpModule, not a transaction.
The session will manage the lifetime of a connection for you, currently, it will close this as early as possible, so you don't need to worry about it.
A transaction should be opened when you want to do some modification to the database, in most cases.

I wanted to understand more as to how the session manages the lifetime of the connection. I searched the code and the only place I found the closeConnection (on the factory) being called is from the SessionImpl's Dispose and Disconnect method. And the Disconnect method is called from the Close method of SessionImpl.

Can you please provide a little more explanation as to how the session is releasing connection "eagerly"?

If it is not, does this mean that we have to call Disconnect() on the session manually?

Regards
Job Samuel.

So this would mean that the sample implementation at http://www.codeproject.com/aspnet/NHibernateBestPractices.asp is misleading. This sample code begins the transaction in startrequest and commits in endrequest.

Incidently the "Hibernate in Action" book also suggests (in the topic "Application Transactions") to start and commit transaction in the doFilter method (i think they are using servlet chaining).

Is there any issue of scalability in this pattern or am I just imagining things?

Regards
Job Samuel.

Check the code for Beta 3, is has this feature.
You don't need to handle this yourself, or call Disconnect.

"This sample code begins the transaction in startrequest and commits in endrequest." - There are good reasons to want to do that, having a consistent view of the DB is one, for instnace.
My personal preference is to only open a transaction when I am doing data modifications, though.

That was what I was looking for, good to see it in Beta-3

Thanks
Job Samuel

There is another approach you may want to consider for 'web-biz layer - db' designed application. The Web layer makes requests of the biz layer and it either returns a DataSet (for large amounts of data) or a single object (which may contain reference to other objects). When a single object is returned it contains within it a reference to a DBSession (which contains the Hibernate Session). All objects/routines used the DBSession class for all DB interactions: Save(), Delete(), etc. The DBSession's Save and Load functions manage the DB connections such that each load request caused the system to re-connect to the DB, retrieve the object and then release the DB connection. All DB connections are released after use and only the Hibernate session state is maintained across DB calls.

The Hibernate session is then set in the returned data object. This enables Hibernate to keep the session around between calls to the DB, and enables dynamic updates to work correctly (reducing concurrency issues for Web applications).

The only thing to watch out for - if your Web page needs multiple "top level" objects on the same page (within the same lifecycle) from the biz layer you must manually add these additional objects to the SAME hibernate session.