Question

I see there are 2 possible scenarios as to the session handling:

1. Open one single ISession per request. Open it at request start and close it at request end.
2. Open one ISession per conceptual “unit of work”. Many sessions are created for a request.

The approach #1 is the one I’m doing now. I’m a little bit worried about it because, although it works, it’s a little bit difficult to debug. For instance, I have an object not being saved (even though I ordered it to) and I’m having trouble debugging since there’s a LOT of things happening during a complete request life-cycle.

The approach #2 seems to be the standard best-practice (not sure about ASP.NET) and I’m sure it’s pretty easier to debug. The problem I see is about inter-session communication. For instance: My Page class holds a reference to the User, which is a persistent object. Many of the operations receive the user as parameter. As the user belongs to a different session, I can’t pass it as a parameter.

I’m biased to #2, but I don’t know if it’s the best practice, nor how to deal with cross-session object.

Thanks.

Answer 1

Most people do Session-Per-Request for the reasons you outline and for simplicity.

However, you can open and commit transactions for each “unit of work”. So you will have many transactions for each session. (It is also usual practice to make sure that when the transaction is committed, the session is flushed at the same time).

For example, after clicking the save button, open and commit a transaction.

The session will take care of keeping track of all your entities. The transaction will take care of flushing to the database when necessary.

With this setup it should be easier to debug your problem.