el momento de cerrar la conexión, Statement, PreparedStatement y conjunto de resultados de JDBC

Question

algunas preguntas sobre JDBC de codificación:

1. Para una sola aplicación cliente, ¿necesitamos un pool de conexiones?
2. ¿Es una buena idea crear una conexión al principio y mantenerla viva sin cerrarla hasta la salida de la aplicación? ¿Por qué?
3. PreparedStatement está asociado a Connection, si mi conexión no se cierra después de cada consulta, ¿por qué no mantener vivo el PreparedStatement y reutilizarlo en otros métodos?
4. si creamos una consulta Preparada para cada consulta, ¿la base de datos sabe que es el mismo PreparedStaement e ignora las acciones innecesarias después de la primera vez?
5. ¿PreparedStatement no se crea una vez y se reutiliza muchas veces? Si es así, ¿por qué necesita cerrarlo cada vez?

Sé que la llamada a close() liberará el recurso. Pero si sabemos que vamos a usarlo más tarde, ¿por qué liberarlo y luego solicitarlo de nuevo más tarde?

¿Qué hay de la aplicación de varios clientes? Necesitamos el grupo de conexiones, por lo que debemos crear y cerrar Connection, Statement y PreparedStatement cada vez.

gracias,

Answer 1

personal que haría uso de una piscina ya que esto se hará cargo de la totalidad de la gestión de recursos para usted. Si sus requisitos de conexión cambian, puede modificar fácilmente la configuración del grupo. Con un grupo en su lugar puede abrir/cerrar conexiones y declaraciones preparadas de acuerdo con best-practice y dejar la administración de recursos al grupo.

Por lo general, cuando se utiliza una piscina:

• cerrar una conexión en realidad acaba de devolverlo a la piscina
• el acto de preparar una declaración, o bien recuperar una declaración preparada previamente de caché de la declaración de la conexión, o si uno no está disponible, cree una nueva declaración y almacénela en caché para usarla más adelante.
• el acto de cerrar un PreparedStatement simplemente lo devolverá al caché de sentencias de la conexión.

Por otra parte - en función de la aplicación de la piscina - puede ser capaz de que le notifique cuando hay fugas de recursos que hacen más fácil identificar este tipo de problemas en el código.

Eche un vistazo a la fuente de una implementación de ejemplo como DBCP - es bastante interesante ver cómo funcionan.

Answer 2

1. Incluso si tiene un único cliente, un conjunto de conexiones puede ser beneficioso. Conectarse a la base de datos puede llevar un tiempo considerable, por lo que hacerlo con mucha frecuencia puede ralentizar su aplicación con solicitudes de red lentas. Además, como @teabot explica, un grupo puede ayudar a identificar si alguna conexión no se está cerrando.

2. No es una buena idea abrir una conexión y dejarla abierta para siempre por dos razones. Primero, la conexión puede morir si hay una interrupción temporal de la red. Cuanto más tiempo esté abierto, más probable es que esté muerto cuando sea necesario.En segundo lugar, una transacción fallida puede dejar la conexión en un estado no adecuado para continuar la operación. Lo mejor es generalmente abrir algunas conexiones, reutilizarlas durante cinco o diez minutos y luego reciclarlas.

3. Dependiendo de la base de datos y el controlador, la conexión puede tener una memoria caché preparada. Incluso si usa una conexión diferente, el RDBMS generalmente almacena en caché declaraciones que son exactamente lo mismo, incluidos sus parámetros. Por lo tanto, SELECCIONE * FROM table WHERE value =? como una declaración preparada se almacenará en caché a través de las conexiones, pero si especifica el valor del parámetro como SELECCIONAR * FROM tabla WHERE value = 'your_data', entonces probablemente no se almacenará en el caché del servidor.

4. Como se explica en 3, depende de la implementación de RDBMS, haga un punto de referencia.

5. No es necesario cerrar y volver a preparar una declaración que se va a reutilizar con diferentes parámetros. Simplemente establece de nuevo los parámetros y ejecuta.

Para clientes múltiples, la base de datos siempre tendrá un límite de conexión simultánea que generalmente no es un número grande. Si todos los clientes pasan por una aplicación web, entonces un grupo como DBCP está bien. Pero obviamente no es deseable crear un grupo para cada cliente con varias conexiones abiertas permanentemente.