1

Topic: Multi-threaded access to a DB

Good afternoon! Help to understand such question, please. (I not  absolutely) got to me a legacy-code in which reversal to a DB goes sql-inquiries through DbCommand. Questions: 1. DbCommand supports a multithreading, or it is necessary to surround it with locks? 2. Looked a passage subject on EF. There are used async/await.  that EF not . But in examples everywhere it is used EF through async/await and anywhere there are no locks. I do not understand, how asynchronous call EF helps thread safety support? - Yours faithfully, Arhipov Dmitry.

2

Re: Multi-threaded access to a DB

Hello, BlackHorse, you wrote: BH> Good afternoon! BH> help to understand such question, please. (I not  absolutely) got to me a legacy-code in which reversal to a DB goes sql-inquiries through DbCommand. Questions: BH> 1. DbCommand supports a multithreading, or it is necessary to surround it with locks? BH> 2. Looked a passage subject on EF. There are used async/await.  that EF not . But in examples everywhere it is used EF through async/await and anywhere there are no locks. I do not understand, how asynchronous call EF helps thread safety support? BH> - BH> yours faithfully, BH> Arhipov Dmitry. DbCommand and DbContext at EF it is one-time objects for handling of one request from one user, more often they are used so, therefore locks here are not used. Isolation levels of transactions are used only. async/await it is simple api for an asynchronous call.

3

Re: Multi-threaded access to a DB

Hello, BlackHorse, you wrote: BH> Good afternoon! BH> help to understand such question, please. (I not  absolutely) got to me a legacy-code in which reversal to a DB goes sql-inquiries through DbCommand. Questions: BH> 1. DbCommand supports a multithreading, or it is necessary to surround it with locks? If DbCommand it is used correctly - locks are not necessary. The correct usage: for each operation to create DbConnection, to create necessary DbCommand, to execute commands (transactions to add to taste), to beat . At such approach DbCommand it is not rummaged with other flows, therefore locks are not necessary. BH> 2. Looked a passage subject on EF. There are used async/await.  that EF not . But in examples everywhere it is used EF through async/await and anywhere there are no locks. I do not understand, how asynchronous call EF helps thread safety support? I suspect that here the same. The objects necessary for request, form only at the moment of request. In itself async/await have no direct relation to object lock

4

Re: Multi-threaded access to a DB

Hello, Qulac, you wrote: Q> Hello, BlackHorse, you wrote: BH>> Good afternoon! BH>> help to understand such question, please. (I not  absolutely) got to me a legacy-code in which reversal to a DB goes sql-inquiries through DbCommand. Questions: BH>> 1. DbCommand supports a multithreading, or it is necessary to surround it with locks? BH>> 2. Looked a passage subject on EF. There are used async/await.  that EF not . But in examples everywhere it is used EF through async/await and anywhere there are no locks. I do not understand, how asynchronous call EF helps thread safety support? BH>> - BH>> yours faithfully, BH>> Arhipov Dmitry. Q> DbCommand and DbContext at EF it is one-time objects for handling of one request from one user, more often they are used so, therefore locks here are not used. Isolation levels of transactions are used only. async/await it is simple api for an asynchronous call. 1. Probably, then at EF there is pool DbContext (differently, would be slowly each time on new to connect) and it somewhere is adjusted? 2. Means for "manual usage" DbContext, DbCommand it is necessary most to do locks?

5

Re: Multi-threaded access to a DB

Hello, vmpire, you wrote: V> the Correct usage: for each operation to create DbConnection, to create necessary DbCommand, to execute commands (transactions to add to taste), to beat . V> At such approach DbCommand it is not rummaged with other flows, therefore locks are not necessary. And in practice all so do or practise a pool of connections? I am am disturbed by a question of duration of operation - a new connection long forms.

6

Re: Multi-threaded access to a DB

Hello, BlackHorse, you wrote: BH> And in practice all so do or practise a pool of connections? I am am disturbed by a question of duration of operation - a new connection long forms. Yes, the pool of connections here was implied.

7

Re: Multi-threaded access to a DB

Hello, BlackHorse, you wrote: V>> the Correct usage: for each operation to create DbConnection, to create necessary DbCommand, to execute commands (transactions to add to taste), to beat . V>> At such approach DbCommand it is not rummaged with other flows, therefore locks are not necessary. BH> and in practice all so do or practise a pool of connections? I am am disturbed by a question of duration of operation - a new connection long forms. At ADO.NET inside already there is a pool of connections, it uses it. It even can be controlled from connection string or from the code Therefore one more pool of the second level manually or attempts of reusage of connection do not lead to productivity improving, and here hardly perceptible errors can fairly tangle and add the code. Here on this point in question it is written explicitly: https://docs.microsoft.com/en-us/dotnet … on-pooling Keys in ConnectionString: https://docs.microsoft.com/en-us/dotnet … work-4.7.1

8

Re: Multi-threaded access to a DB

Hello, vmpire, you wrote: V> At ADO.NET inside already there is a pool of connections, it uses it. It even can be controlled from connection string or from the code V> Therefore one more pool of the second level manually or attempts of reusage of connection do not lead to productivity improving, and here hardly perceptible errors can fairly tangle and add the code. V> here on this point in question it is written explicitly: https://docs.microsoft.com/en-us/dotnet … on-pooling V> Keys in ConnectionString: https://docs.microsoft.com/en-us/dotnet … work-4.7.1 Many thanks!