conexión de base de datos compartida frente a conexiones de base de datos privadas

Question

Tratando de averiguar cómo administrar/usar conexiones de base de datos de larga vida. Tengo muy poca experiencia de este tipo, ya que utilicé DB solo con sistemas pequeños (hasta unos 150 usuarios simultáneos, cada uno tenía su propio usuario/pase DB, por lo que había hasta 150 conexiones DB de larga duración en cualquier momento) o páginas web (cada solicitud de página tiene su propia conexión de base de datos que dura menos de un segundo, por lo que el número de conexiones de base de datos concurrentes no es enorme).

Esta vez habrá un servidor Java y un cliente Flash. Java se conecta a PostgreSQL. Se espera que las conexiones sean de larga duración, es decir, se espera que comiencen cuando el cliente Flash se conecte al servidor Java y finalice cuando el cliente Flash se desconecte. ¿Sería mejor compartir una única conexión entre todos los usuarios (clientes) o hacer una conexión privada para cada cliente? ¿O alguna otra solución sería mejor?

*) Individual/conexión compartida:

• (+) pros
  • sólo una conexión DB para todo el sistema
• (-) contras:
  • transacciones no se puede utilizar (p. ej., "user1.startTransaction(); user1.updateBooks(); user2.updateBooks(); user1.rollback();" to una única conexión compartida sería deshacer los cambios que se hacen por usuario2)
  • largas consultas de un usuario podría afectar a otros usuarios (no estoy seguro acerca de esto, sin embargo)

*) Las conexiones privadas:

• (+) pros
  • no hay problemas con las transacciones :)
• (-) contras:
  podría ser necesario
  • gran número de conexiones simultáneas, es decir, si hay 10000 usuarios en línea, se requieren conexiones 10000 DB, que parece ser demasiado alto número :) no lo hago sin embargo, sabemos algo sobre el número esperado de usuarios, ya que aún estamos en proceso de investigación y planificación.

Una solución sería introducir los tiempos de espera, es decir, si la conexión DB no se utiliza para 15/60/900 (?) Segundos, se desconecta. Cuando el usuario necesita nuevamente una base de datos, se vuelve a conectar. Esta parece ser una buena solución para mí, pero me gustaría saber cuáles podrían ser los límites razonables para esto, por ejemplo, cuál podría ser el número máximo de conexiones DB concurrentes, qué tiempo de espera debería usarse, etc.

Otro La solución consistiría en agrupar las consultas en dos "tipos": un tipo que puede usar de forma segura una única conexión compartida de larga duración (por ejemplo, "actualizar el usuario set last_visit = now() donde id =: user_id") y otro tipo que necesita un conexión de vida corta privada (p. ej., algo que potencialmente puede hacer un trabajo pesado o usar transacciones). Esta solución no parece ser atractiva para mí, aunque si así es como debe hacerse, podría intentar hacer esto ...

So ...¿Qué hacen otros desarrolladores en estos casos? ¿Hay alguna otra solución razonable?

Answer 1

No utilizo conexiones de larga vida. Utilizo un grupo de conexiones para administrar las conexiones, y las guardo solo durante el tiempo que sea necesario para realizar una operación: obtener la conexión, realizar mi operación SQL, devolver la conexión al grupo. Es mucho más escalable y no sufre problemas de transacción.

Deje que el contenedor administre el grupo por usted, para eso sirve.

Answer 2

Al usar una sola conexión, también obtiene un rendimiento muy bajo porque el servidor de la base de datos solo asignará una conexión para usted.

Definitivamente necesita un grupo de conexión. Si su aplicación se ejecuta dentro de un servidor de aplicaciones, use el grupo de contenedores. O puede usar una biblioteca de conjunto de conexiones como c3p0.