Isn't NHibernate's "one session per request" pattern a bit dangerous for long web requests?

In the company I work for, we're using a NHibernate session wrapper that disposes all the sessions opened in the current web request at the end of the same request, and commits all the associated transactions (we're working in a multi-database environment, and we create a session for every database).

Also, in the session wrapper we're using, the session and the transactions are coupled, and we can't commit a transaction without disposing its session.

The problem is that, sometimes, a transaction stays open for all the request life, and database tables stays locked for much too time.

... are we missing somethi开发者_如何学编程ng?

Session per request is only one way to do session lifecycle management. It happens to be the recommended strategy for web apps, but NHibernate is really indifferent to how you manage your session lifetime.

You can certainly use sessions that have shorter or longer lives than a single request. If you have use cases that would work better in that way, by all means, go for it.

Don't let your session wrapper put unnecessary constraints on your ability to adapt NHibernate to the needs of your application.

Sound more like a limitation of the session manager you're using. Granted all open transactions should be disposed at the end of the session (and rolled back if not committed) - you should be able to create and commit transactions as needed. It really comes down to how you want to handle the service call - if you want it treat the service call as one atomic transaction I think you are stuck with locking until completion. Lot's of options here.