Зачем вообще вызывать метод SqlClient.SqlDataReader Close()?

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

Дальнейшее чтение

• Объяснение пула соединений ADO.NET от O'Reilly
• Извлечение данных с помощью DataReader от Microsoft содержит общий обзор. DataReaders.

~ Уильям Райли-Лэнд

@лейтенант Фрост

Как правило, в нашем магазине мы явно оборачиваем все вызовы базы данных в блок Try...Finally, при этом раздел finally перехватывает и закрывает подключения к данным. Это стоит крошечных усилий, чтобы избавить себя от головной боли при устранении неполадок.

У меня есть похожее правило, но я требую, чтобы объекты, реализующие IDisposable, использовали блок «использование».

using (SqlConnection conn = new SqlConnection(conStr))
{
     using (SqlCommand command = new SqlCommand())
     {
        // ETC
     } 
}

Блок using сразу же вызывает Dispose при выходе из области видимости, даже с исключением.

Одна из хороших практик (если вы не используете соединения повторно) состоит в том, чтобы добавить Command Behavior в SqlDataReader, чтобы закрыть соединение, когда оно будет удалено:

SqlDataReader rdr = cmd.ExecuteReader( CommandBehavior.CloseConnection );

Добавление этого гарантирует, что соединение с базой данных будет закрыто, когда объект SqlDataReader будет закрыт (или собран мусор).

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

Я думаю, что все остальные говорили это, но я хотел, чтобы это было ясно:

Выход за рамки не означает немедленную сборку мусора.

Ваше приложение должно «хорошо играть» на нескольких уровнях. Закрытие соединений поможет вам сделать это. Давайте рассмотрим некоторые из этих уровней.

1: Вы не полагаетесь на сборку мусора. В идеале сборка мусора не должна существовать. Но это так. Но, безусловно, вы не должны полагаться на это.

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

3: Вы не генерируете сетевой трафик. Каждое соединение с базой данных по существу представляет собой TCP-соединение. Оставляя его открытым, вероятно, генерируется сетевой трафик типа «Вы все еще там?». да. Небольшой трафик да, но в переполненной сети это плохая практика. И сам SQL Server использует ресурсы, чтобы поддерживать ваше соединение. Ресурсы, которые другие люди, пытающиеся получить доступ к этому серверу sql, могли бы лучше использовать.

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

Когда в вашем веб-приложении всего 100 пользователей, вам может быть все равно. Но как насчет 100 000? Всегда учитывайте, что происходит при масштабировании.

Если вы не закроете его явно, то он будет ждать, пока сборщик мусора «соберет» его... Только после этого он будет выпущен обратно в пул соединений ADO.Net для повторного использования другим соединением. запрос, поэтому в течение всего прошедшего времени любые другие запросы на соединение должны будут создавать совершенно новый запрос, даже если там есть совершенно хороший неиспользованный запрос, который можно было бы использовать...

В зависимости от того, сколько времени осталось до запуска GC и сколько запросов к базе данных выполняется, у вас могут закончиться доступные подключения к базе данных.

Но в методе Command.ExecuteReader() есть необязательный параметр, который называется CommandBehavior. Это перечисление со значениями: CommandBehavior.Default, CommandBehavior.SingleResult, CommandBehavior.SchemaOnly, CommandBehavior.KeyInfo, CommandBehavior.SingleRow, CommandBehavior.SequentialAccess и CommandBehavior.CloseConnection.

Это перечисление имеет атрибут FlagsAttribute, который допускает побитовую комбинацию значений его членов. Здесь важно последнее значение (CommandBehavior.CloseConnection). Он сообщает объекту Command закрыть соединение при закрытии устройства чтения данных. http://msdn.microsoft.com/en-us/library/system.data.commandbehavior.aspx

К сожалению, по умолчанию НЕ закрывать соединение при закрытии средства чтения данных, но вы можете (и должны) передать этот параметр как CommandBehavior.CloseConnection, если вы хотите, чтобы ваш метод немедленно освобождал соединение обратно в пул, когда вы закончите с Это...

«Управляемый» ресурс, на который ссылается термин «управляемый код», — это память. Вот и все. Любой другой дефицитный ресурс необходимо обернуть одноразовым шаблоном, включая соединения с базой данных.

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

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

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

Как правило, в нашем магазине мы явно оборачиваем все вызовы базы данных в блок Try...Finally, при этом раздел finally перехватывает и закрывает подключения к данным. Это стоит крошечных усилий, чтобы избавить себя от головной боли при устранении неполадок.