¿Por qué usar Singleton para administrar la conexión db?

Question

Sé que esto se ha preguntado antes aquí y en todas partes, pero no puedo obtener una explicación clara, así que voy a volver a lanzarlo. Entonces, ¿qué es todo el alboroto sobre el uso de un singleton para controlar la conexión db en su aplicación web? A algunos les gusta que algunos lo odien, no lo entiendo. Por lo que he leído, "es para asegurar que siempre haya una sola conexión activa a su DB". Quiero decir por qué es eso algo bueno? 1 conexión de base de datos activa en una aplicación web impulsada por datos que procesa solicitudes múltiples por problemas de hechizos de segundo, ¿no? Por la razón que sea, nadie puede explicar esto correctamente. He estado en toda la web. Sé que soy grueso.

Answer 1

Tienes razón, generalmente esto no es lo que quieres.

Sin embargo, hay muchos casos en los que necesita acelerarse hasta una sola conexión. Al serializar su acceso a la base de datos a través de un singleton, puede abordar otros problemas o restricciones como carga, ancho de banda, etc.

He hecho algo similar en el pasado para una aplicación de procesamiento masivo. En su lugar, sin embargo, utilicé un semáforo para sincronizar el acceso a la base de datos, por lo que podía permitir n operaciones simultáneas de db.

Answer 2

Garantiza que cada cliente que use su sitio solo obtenga una conexión con el db. Realmente no desea que se establezca una nueva conexión cada vez que un usuario realiza una acción que creará una consulta db. No solo por razones de rendimiento con el apretón de manos de la conexión involucrado, sino para disminuir la carga en el servidor de db.

Las conexiones DB son un bien preciado, y esta técnica ayuda a minimizar la cantidad utilizada en un momento dado.

Answer 3

Es posible que desee utilizar un singleton debido a las limitaciones del servidor de la base de datos, por ejemplo, un servidor puede limitar el número de conexiones.

Mi razón principal consciente es que usted sabe qué conexiones se pueden gestionar/cerrar, etc., simplemente hace las cosas un poco más organizadas cuando no tiene conexiones innecesarias y redundantes.

Answer 4

No creo que sea una respuesta simple. Por ejemplo, en ASP.NET, la plataforma implementa la agrupación de conexiones de forma predeterminada, por lo que ajustará automáticamente un "grupo" de conexiones y las reutilizará para no crear y destruir constantemente objetos caros.

Sin embargo, digamos que estaba escribiendo una aplicación de recopilación de datos que supervisaba 200 fuentes de entrada separadas. Cada vez que una de esas entradas cambia, desencadena un hilo que registra el evento en la base de datos. Diría que podría ser un mal diseño si existe la posibilidad de que incluso una fracción de ellos pueda dispararse al mismo tiempo. De repente, tener 20 o 40 conexiones de bases de datos activas es ineficiente. Es posible que sea mejor poner en cola las actualizaciones, y mientras haya actualizaciones en la cola, una conexión singleton las saca de la cola y las ejecuta en el servidor. Es más eficiente porque solo tiene que negociar la conexión y la autenticación una vez. Una vez que no haya actividad durante un tiempo, puede optar por cerrar la conexión. Este tipo de comportamiento sería difícil de implementar sin un administrador de recursos central como un singleton.

Answer 5

"solo una conexión activa" es una declaración muy limitada para la ilustración. Podría ser un singleton administrando un grupo de conexión. El objetivo de un singleton para las conexiones de bases de datos es que no desea que cada consumidor haga su propia conexión o conjunto de conexiones.

Answer 6

Creo que es posible que desee ser más específico acerca de "utilizar un singleton para controlar la conexión db en su aplicación web". Idealmente, un objeto java.sql.Connection será no seguro para hilos, pero su javax.sql.DataSource puede querer agrupar conexiones, por lo que debe ir a una instancia única para compartir la agrupación.

Answer 7

Las aplicaciones web de alto rendimiento (o incluso de rendimiento medio) usan la base de datos connection pooling, por lo que se puede compartir una conexión de base de datos entre muchas solicitudes web. El singleton suele ser el objeto que gestiona este grupo. Creo que la motivación para usar un singleton es a prueba de idiotas contra los programadores de mantenimiento que de lo contrario podrían instanciar muchos de estos objetos innecesariamente.

Answer 8

estás buscando más una conexión por solicitud, no una conexión para toda la aplicación. aún puede controlar el acceso a él a través de un singleton (almacenando la conexión en la colección HttpContext.Items).

Answer 9

"es para asegurar que siempre haya una sola conexión activa a su base de datos". Creo que sería mejor indicar que cada CLIENTE tiene una sola conexión activa con su base de datos. La razón por la que esto es increíblemente importante es porque quiere evitar interbloqueos. Si tengo DOS conexiones de bases de datos abiertas (como cliente) podría estar actualizando en una conexión, entonces podría tratar de actualizar la misma fila en otra conexión. Esto será un punto muerto que la base de datos no puede detectar. Entonces, la idea del singleton es básicamente asegurarnos de que haya UN objeto que se encargue de distribuir las conexiones de la base de datos a cada cliente. Básicamente. No TIENE que tener un singleton para esto, pero la mayoría de la gente le dirá que simplemente tiene sentido que el sistema solo tenga uno.

Answer 10

Suponiendo que Java está aquí, pero también es relevante para la mayoría de las otras tecnologías.

No estoy seguro de si ha confundido el uso de un singleton simple con un service locator. Ambos son patrones de diseño. Las aplicaciones utilizan el patrón de localizador de servicios para garantizar que haya una sola clase a la que se confíe la responsabilidad de obtener y proporcionar acceso a bases de datos, archivos, colas JMS, etc.

La mayoría de los localizadores de servicios se implementan como singleton, ya que no es necesario que los localizadores de servicios múltiples realicen el mismo trabajo. Además, es útil almacenar en caché la información obtenida de la primera búsqueda que luego puede ser utilizada por otros clientes del localizador de servicios.

Por cierto, el argumento sobre

"Es para asegurarse de que siempre hay sólo una conexión activa a su base de datos"

es falsa y engañosa. Es muy posible que la conexión se pueda cerrar/recuperar si se deja inactiva durante un período de tiempo bastante largo. Así que almacenar en caché una conexión a la base de datos está mal visto. Hay una desviación de este argumento; la "reutilización" de la conexión obtenida del grupo de conexiones se recomienda siempre que lo haga con el mismo contexto, es decir, dentro de la misma solicitud HTTP o solicitud del usuario (lo que corresponda). Esto se hace obviamente, desde el punto de vista del rendimiento, ya que establecer nuevas conexiones puede resultar una operación costosa.