How does it work the Session Per Request pattern?

Question

We're working on a project using ASP.NET MVC4. In one of team's meeting, came out an idea of using Session per request pattern.

I did a little search and found out some questions here in SO saying - in general - that this pattern (if may be called) it's indicated to frameworks ORM.

A little example

//GET Controller/Test

public ActionResult Test()
{
     //open database connection

     var model = new TestViewModel 
                 {
                      Clients = _clientService.GetClients(),
                      Products = _productService.GetProducts()
                 };

     //close database connection
     return View(model);
}

Without session per request:

//GET Controller/Test

public ActionResult Test()
{
     var model = new TestViewModel 
                 {
                      Clients = _clientService.GetClients(), // Open and close database connection
                      Products = _productService.GetProducts() // Open and close database connection.
                 };
     return View(model);
}

Doubts

1. To contextualize, how does session per request works?
2. Is it a good solution?
3. What is the best way to implement it? Open the connection on web?
4. Is it recommended in projects with complex queries / operations?
5. Is there a possibility of giving a concurrency problem when transactions are involved?

Answer 1

Looks like you mean "DB context per request". You can achieve it with Unit of work pattern.

Simple implementation of that you can check int this article of Radu Pascal: https://www.codeproject.com/Articles/243914/Entity-Framework-context-per-request

Another implementation (for Entity Framework and NHibernate), you can find in ASP.NET Boilerplate which is more complex: http://www.aspnetboilerplate.com/Pages/Documents/Unit-Of-Work

Answer 2

In a web (web application, wcf, asp.net web api) it is a good idea to use one DB context per request. Why? Because the requests are short lived, at least that is the idea or your application will have a slow response time, so there is no point in creating many db contexts.

For example, if you are using EF as ORM and you issue a request to Find method, EF will first search for whatever you are asking in the local cache of the db context. If it is found, it will simply return it. If not found, it will go to the database and pull it out and keep it in the cache. This can be really beneficial in scenarios where you query for the same items multiple times until your web application has fulfilled the request. If you create a context, query something, close the context then there is a possibility you will make many trips to the database which could be avoided.

To elaborate further, imagine you create many new records: a customer record, an order record, then do some work and then based on whatever criteria you create some discount records for the customer, then some other records, and then some orderitem records. If you use the Single Context Per-Request approach, you can keep adding them and call SaveChanges at the end. EF will do this in one transaction: either they all succeed or every thing is rolled back. This is great because you are getting transactional behavior without even creating transactions. If you do it without Single Context Per-Request approach, then you need to take care of such things yourself. That does not mean in the Single approach, everything needs to be in one transaction: You can call SaveChanges as many times as you want within the same http request. Consider other possibilities, where you pull a record, and later on decide to edit the record and then edit it some more: again in the Single approach, it will all be applied to the same object and then saved in one shot.

In addition to the above, if you still want to read more then you may find this helpful. Also, if you search for Single Context Per-Request, you will find many articles.