when should I use the session-per-request pattern

Question

I see this pattern everywhere, but Linq to SQL does not implement it. If Session/Unit-of-Work objects are lightweight (can be created and destroyed without performance penalty), and connection pooling keeps database connections alive, why and when do I need the session-per-request pattern?

Answer 1

I believe the idea of session-per-request is more about when you open and close the session, not about getting performance improvements.

The idea is that

1. Opening a session will start a transaction before your code is ever called
2. Your business logic and your framework has full access to the database until the last possible moment
3. Your transaction is committed for you, instead of having to do it each time yourself

The idea of #2 is important so that you can mix web frameworks and lazy loading of data; if a getter method is called while rendering your data after your code has been executed, and you closed the session, you couldn't lazily load that getter's result.