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

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

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

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

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

Спасибо -

Джонатан

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

Есть два способа:

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

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

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

Ответ 3

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

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

Ответ 4

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

из MSDN.

см. здесь Пул соединений (ADO.NET)

Ответ 5

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

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

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