Будут ли объединенные в пул SQL-соединения очищаться, если на них все еще есть ссылка?

Я могу сказать вам со 100% уверенностью, что соединение НЕ возвращается в пул, пока не будет освобождено. У меня был сеанс создания временной таблицы, и я оставил ее висящей в ожидании ввода пользователя. Пользователь возвращается через 6 минут, нажимает кнопку и продолжает с тем же SPID, и жизнь во временной таблице продолжается.

Применяя логику, это имеет смысл, потому что можете ли вы представить хаос, если вы потеряете SPID только потому, что вы бездействовали в течение X минут? Должны ли вы продолжать «пинговать» SQL Server с помощью команды только для того, чтобы поддерживать его в рабочем состоянии? (это было бы безумием)

---

Похоже, вы путаете два понятия. Когда соединение закрывается, оно возвращается в пул. Если он выходит за рамки, он неявно закрывается -> возвращается в пул. Ссылка на "бездействие" относится к тому моменту, когда соединение в пуле становится бездействующим, а не когда на него активно ссылаются и не закрывается. Удержанное соединение даже не находится в пуле, чтобы иметь право на какой-либо тип очистки. Освобождение ресурсов из пула имеет смысл, потому что веб-приложение может легко увеличить количество подключений до сотен, а затем в течение следующих нескольких месяцев оставаться на уровне около 20 или около того активных одновременных подключений.

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

«Удерживаемая ссылка» здесь несущественна, точка «открыта». Чтобы правильно переработать соединение, вам нужно Dispose() или Close() его.

Я только что запустил следующую программу:

        var conn = new SqlConnection("...");
        conn.Open();
        conn.ExecuteNonQuery("select null");
        Thread.Sleep(TimeSpan.FromMinutes(11));
        conn.ExecuteNonQuery("select null");

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

Это, конечно, ничего не доказывает (только если оно не работало правильно). Reflector показывает, что пул очищается в первый раз через 6,5 минут, а затем каждые 30 секунд:

private Timer CreatePruningTimer()
{
    return new Timer(new TimerCallback(this.PruneConnectionPoolGroups), null, 240000, 30000);
}

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

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

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

Я не доверяю этому. Говоря языком Байеса, документы Microsoft являются убедительными доказательствами, но при наличии веских контрдоказательств можно прийти к противоположному выводу.

У меня есть следующие доказательства того, что открытые соединения не закрываются без причины:

1. Это приведет к случайным сбоям, которые невозможно предотвратить (только повторной попыткой).
2. Это прервало бы транзакции, которые просто прекрасны
3. Это сделало бы длительные транзакции невозможными.
4. Я не вижу причины, почему такое поведение должно иметь место
5. Предложение в документах можно интерпретировать следующим образом: пул периодически возвращает соединения, которые не были закрыты, но соответствующий объект SqlConnection был подвергнут сборке мусора (обнаружение этого с помощью WeakReference или чего-то подобного). Я предполагаю, что автор документа Microsoft имел в виду это или не понял проблему (правдоподобно!)
6. Тест не выявил проблему
7. Как SSMS удается выполнять часовые запросы? На SSMS должно распространяться такое же ограничение.