Должен ли я сохранить sqlconnection в моем уровне доступа к данным?

Question

Похоже, что быстрое открытие и закрытие sqlconnections связано с большими накладными расходами. Должен ли я сохранить соединение (одно, для каждого клиента, для каждой базы данных) или продолжить объявлять новый объект sqlconnection всякий раз, когда он мне нужен, и убедиться, что я очищаю после себя?

Что ты наделал? Что работало хорошо, а что плохо?

Answer 1

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

Если вы используете SQL Server: http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

OLE DB, ODBC, Oracle: http://msdn.microsoft.com/en-us/library/ms254502.aspx

Статья Дино Эспозито: http://www.wintellect.com/Articles/ADO%20NET%20Connection.pdf

Вы можете переопределить поведение пула по умолчанию с помощью имени / значений строки соединения: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. См. Вторую таблицу настроек, содержащую «Время жизни соединения».

Answer 2

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

Answer 3

Если вы используете ту же строку подключения, ваши подключения будут объединены. У вас должно быть открыто только то соединение, которое вам нужно.

Answer 4

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

Билл Вон имеет ряд полезных статей о пуле соединений и доступе к данным, в том числе этот

Answer 5

У меня была та же мысль, поэтому я использовал то же соединение в узком цикле, чтобы не создавать экземпляр другого, когда мне это нужно. Но иногда трудно отследить это и отладить, если вы отключите DataReader от соединения, а затем попытаетесь сделать еще один, пока тот же читатель все еще активен, тогда вы получите исключение. Поэтому я бы порекомендовал его, только если он действительно частый, как плотная петля, иначе это не стоит хлопот.

Answer 6

В течение многих лет клиент вел единую постоянную связь с базой данных. Проблема заключается в обнаружении прерывистого сбоя подключения и постепенного повторного подключения. Довольно часто вы не будете знать, что соединение не установилось, пока не попробуете его использовать (т. Е. При выборе select будет выброшена «Общая ошибка SQL»)

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

DbConnection conn = Database.GetConnection();
try
{
   //do stuff with the connetion
   ...
}
finally
{
   Database.DisposeConnection(conn);
}

Мы делаем это, потому что требуется инициализация, когда мы подключаемся к базе данных (мы храним информацию - CONTEXT_INFO SQL Server, и мы должны очистить эту информацию при отключении)