¿Qué tan malo es no disponer de () SqlConnections?

Yo diría que lo mejor que puedes hacer es señalarlos a los patrones y prácticas de Microsoft con respecto a Dispose() aquí . Permítales ver las consecuencias completas de no utilizar esta herramienta que está justo frente a ellos.

Si no llama al método Dispose en una conexión SQL, cuando termine de usarlo, esa conexión NO volverá al grupo de conexiones.

Si tiene problemas de rendimiento, supongo que las conexiones máximas se abren en su base de datos. Un DBA podría fácilmente confirmar esto.

Las Mejores Prácticas de Microsoft requieren que coloque su código de conexión dentro de una declaración de Uso, asegurándose de que se elimine la conexión y que la conexión se devuelva al grupo.

El grupo de conexiones de la base de datos tiene un tamaño limitado y, si se llena, las nuevas conexiones esperarán a que se liberen las conexiones antiguas. Si no los desecha tan pronto como haya terminado con ellos, eventualmente se liberarán cuando se ejecute el finalizador, pero eso es un tiempo indeterminado en el futuro ... Así que en Lo mejor es que vas a ver grandes retrasos al abrir nuevas conexiones.

En el peor de los casos, es posible que hayan deshabilitado el conjunto de conexiones. Quizás descubrieron que después de un tiempo su aplicación estaba devolviendo los errores de "tiempo de espera para la conexión" y deshabilitando el grupo de conexiones "solucionado" ese problema. Sin embargo, esto es mucho peor porque significa que estás creando una conexión completamente nueva cada vez, lo que sorprendentemente requiere muchos recursos. Si tiene cientos de conexiones abiertas a la base de datos, no es de extrañar que esté viendo problemas de rendimiento.

La forma correcta de resolver todos estos problemas es deshacerse de su conexión tan pronto como haya terminado con ella. La mejor idea es mantener la conexión abierta exactamente el tiempo que sea necesario, y no más.

En cualquier aplicación seria, diría que es bastante malo. Dejar estos objetos flotantes no solo mata el rendimiento, sino que también es simplemente poco profesional. La buena noticia es que Microsoft implementa Finalize en la jerarquía de objetos.

~Object()
{
    this.Dispose(false);    
}

public void Dispose()
{
    this.Dispose(true);
    GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
    // ...
}

Toma System.Data.SqlClient.SqlConnection por ejemplo:

System.ComponentModel.Component <-- Implements the Finalize dispose pattern.
    |
System.Data.Common.DbConnection
    |
System.Data.SqlClient.SqlConnection

Los objetos se eliminarán con el tiempo, pero la naturaleza no determinista puede causar estragos en el rendimiento.

Bueno, para empezar, no estás terminando la conexión. Por lo tanto, debe: a) Se eliminará automáticamente o b) Se realizará un ciclo y se actualizará a pesar de que el cliente no tiene ningún uso para ello.

Supongo que b) debido al impacto de rendimiento que estás describiendo. Sin embargo, es probable que esa no sea la única razón.

DEBE cerrar sus conexiones, preferiblemente en el lado del cliente, pero también debe implementar una protección contra fallas en el lado del servidor. De lo contrario, acaba de acumularse información adicional que su servidor de base de datos debe procesar hasta que se libere en el momento en que Dios sabe.