java - sirve - Cuándo cerrar Connection, Statement, PreparedStatement y ResultSet en JDBC

preparedstatement como funciona?

Question

Pocas preguntas sobre la codificación JDBC:

1. Para una aplicación de cliente único, ¿necesitamos un grupo 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 PreparedStatement 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

Personalmente, utilizaría un grupo de servidores, ya que esto se encargará 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 las best-practice y dejar la administración de recursos al grupo.

Por lo general, al usar un grupo:

• cerrar una conexión realmente solo lo devolverá al grupo
• el acto de preparar una declaración recuperará una declaración preparada previamente de la caché de sentencias de Connection, o si no hay una disponible, creará una nueva instrucción y la almacenará en caché para usarla posteriormente.
• el acto de cerrar un PreparedStatement simplemente lo devolverá al caché de sentencias de la conexión.

Además, dependiendo de la implementación de la agrupación, es posible que pueda notificarlo cuando haya filtraciones de recursos que faciliten la identificación de este tipo de problemas en su 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. Según la base de datos y el controlador, la conexión puede tener un caché de declaraciones preparado. 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 benchmark.

5. No es necesario cerrar y preparar nuevamente una declaración que se 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áneo 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.