Question:
An idea arose among developers to use the Session per request pattern – Session per request.
Searching on the subject, I found some topics in the OS that generally said that the indication was for ORM frameworks .
small practical example
//GET Controller/Teste
public ActionResult Teste()
{
//abrir conexão com o banco
var model = new TesteViewModel
{
ListaClientes = _servicoCliente.ObterClientes(),
ListaProdutos = _servicoProduto.ObterProdutos()
};
//fechar conexão com o banco
return View(model);
}
Sem o session per request:
//GET Controller/Teste
public ActionResult Teste()
{
var model = new TesteViewModel
{
ListaClientes = _servicoCliente.ObterClientes(), // Abro e fecho a conexão com o banco no inicio e fim do método, respectivamente.
ListaProdutos = _servicoProduto.ObterProdutos() // Abro e fecho a conexão com o banco no inicio e fim do método, respectivamente.
};
return View(model);
}
Questions:
- To put it in context, how does the session by request consist?
- Is it a good solution?
- What would be the best way to implement it? Open the web connection?
- Is it recommended for projects with complex queries/operations?
- Is there a chance of a concurrency problem when there are operations/transactions involved?
Answer:
- To put it in context, how does the session by request consist?
To make a request to a database, it is necessary to open a connection with that same database.
You can consider that there is a session while this connection is open. In other words, you can make as many requests as you like while not closing your call (for the duration of the session).
Thus, the concept of "session by request" supports the ideology that it should only make one request to the database each time it connects.
- Is it a good solution?
Answer 1
It depends on your application, at least this is the answer that all users here would accept without any controversy.
Answer 2
In principle not. In my perspective it is much better to establish a session for each business process. The reason is simple. It may be just speculation, but I would say that most applications need to perform atomic possessions, using for example transactions (which make one or more requests to the database).
I had to test whether it was possible to do multiple operations within a transaction on different connections and it didn't work. Even if it did, it wouldn't make sense to do a process piecemeal.
What would be the best way to implement it? Open the web connection?
I don't know what you're talking about, the web application or the database? The most common database communication protocol is eventually TCP, it is also common to use named pipes.
Is it recommended for projects with complex queries/operations?
I think I already explained how I would do in my second answer to question 2.
Is there a chance of a concurrency problem when there are operations/transactions involved?
Well this is exactly one of the problems I mentioned.
I would like to add that the example given may have yet another problem. The AP did not give details about the table schema, so it is not possible to confirm. But imagining that each customer has a list of products then it would have less cost to bring both at the same time (with a join operation, this could be done in a request and consequently in a connection to the database)