Многопоточность и соединение с базой данных

Question

Итак, я пытаюсь найти лучшие практики для подключения к моей базе данных. У меня есть большой .NET GUI, который служит интерфейсом для базы данных MySQL. В настоящее время я открываю соединение при загрузке приложения и использую его для любых взаимодействий, которые мне нужны. Однако весь графический интерфейс является однопоточным.

Когда я начинаю добавлять BackgroundWorkers для больших запросов и выполнения, меня беспокоит мое открытое соединение. Я знаю, например, что у меня может быть одновременно открыт только один dataReader для этого соединения. С несколькими потоками пользователь может попытаться создать больше, чем это.

Каковы преимущества / недостатки сохранения одного открытого соединения для приложения по сравнению с открытием нового соединения для каждого взаимодействия?

Каковы некоторые общие шаблоны проектирования для этого?

1009 * Благодарения и *

Jonathan

Answer 1

Используйте потокобезопасный пул соединений и сохраняйте соединения для каждого потока (не делите соединения между потоками).

Я полагаю, что инфраструктура подключения MySQL .NET поставляется с одной встроенной. Если вы используете одну и ту же строку подключения для всех подключений, просто добавьте «pooling = true» в строку подключения. ( Источник - фрагмент гиперссылки отсутствует, поэтому поищите "объединение" в таблице)

Недостатком этого подхода является то, что некоторые потоки будут блокироваться до тех пор, пока соединение не станет доступным. Вы должны будете учесть это в структуре вашей программы.

Answer 2

Есть 2 способа:

1. Одиночное соединение - в этом случае соединение создается 1 раз и распределяется между всеми запросами, что, если большое количество одновременных запросов приводит к потере производительности, и вы сами должны контролировать сохранение потоков. *

2. Соединение по запросу - в этом случае вы должны открыть соединение и закрыть его сразу после выполнения запроса. Но количество одновременно открытых соединений может быть ограничено сервером. Здесь накладные расходы на создание соединений всегда присутствуют, но решаются с помощью потокового пула соединений, что было хорошей практикой.

Вам необходимо проанализировать и предсказать поведение вашего приложения и выбрать подходящий путь. Если у вас простое приложение, вам, вероятно, не нужно будет использовать пулы. Если приложение требует серьезной нагрузки и будущей масштабируемости, было бы правильно использовать пулы.

Answer 3

Подключение к источнику данных может занять много времени. Чтобы минимизировать стоимость открытия соединений, ADO.NET использует метод оптимизации, называемый пул соединений, который минимизирует стоимость многократного открытия и закрытия соединений. Пулы соединений обрабатываются по-разному для поставщиков данных .NET Framework.

из MSDN.

см. Здесь Пул подключений (ADO.NET)

Answer 4

При одном открытом соединении у вас должна быть максимальная пропускная способность с базой данных. Однако вы в конечном итоге пишете сложный код в своем приложении, чтобы разделить соединение.

Здесь - статья о шаблонах совместного использования ресурсов. Примеры в Аде, но я уверен, что вы все равно можете прочитать их.

Answer 5

Мы провели некоторый тест, прежде чем решить, в какую сторону идти. Я имею в виду между ConnectionAlwaysOpen или ConnectAndDisconnectEachTime.

Как видно из .NET с SQL Server (никогда не пробовал с MySQL), не было видимого снижения производительности ни в одном из подходов (ничего удивительного, поскольку нижние уровни в действительности не отключаются немедленно в сценарии ConnectAndDisconnectEachTime). Но была небольшая разница, которая заставила нас выбрать ConnectionAlwaysOpen. Причиной была поддержка Транзакции. Если вы намереваетесь использовать транзакции, то подключение / отключение НЕ будет работать, я думаю, очевидно, почему.

ConnectionAlwaysOpen, конечно, можно улучшить с помощью существующих пулов соединений или некоторого ручного отложенного кэша пулов соединений, но основная идея остается неизменной. С другой стороны, в веб-приложении этот подход немного сложнее реализовать и поточно-ориентирован, но он может стоить усилий.