问题
I am using ADO.Net for connecting to some Sql Server and Oracle databases, and I want to run some of my queries concurrently.
I use classes from SqlClient namespace for Sql Server and ODP.Net for Oracle. For Sql Server I added MARS option to the connection string, and call asynchronous APIs on SqlCommand. ODP.Net does not provide asynchronous API, so I have to give my concurrent Oracle commands separate threads.
My question is, how should I handle connection objects? Should I create one DbConnection per each database instance and execute commands asynchronously against a single connection, or should I give a separate connection object to each of my concurrent commands? Does a shared connection object become a contention point for multiple commands executing through it simultaneously?
I will write some comparison tests but would love to hear from somebody who has experience with asynchronous database commands. Thank you in advance!
回答1:
Some time ago we faced this issue and chose to handle a separate connection object to each of the concurrent commands. It was an application making a lot of use of the database (for each page there were around 40 queries executed). We saw this was very slow because of the connection creation.
So, we changed it to a single connection (a singleton) used by every command executed. This fixed the issue and we were happy to see the application was responding faster. However, the application began growing and the need of transactions was urgent, but we faced the problem that this was not possible in our model. We ended using a mix: whenever the connection needed transactions we created a new one, if no transactions were needed then we reused the one that had been created in the singleton.
What i would do now is to use a single connection and use a transaction pattern inside the stored procedures called; avoiding having to handle the transaction on the application server.
Hope it was helpful.
来源：https://stackoverflow.com/questions/10239977/ado-net-best-practice-single-vs-multiple-connections-when-making-asynchronous