parametros - preparedstatement java update
¿Hay alguna razón para nunca cerrar una conexión JDBC? (3)
Estoy leyendo un código del último desarrollador que trabajó en el sistema y nunca cierra ninguna conexión con la base de datos. Solo cierra las conexiones PreparedStatement y ResultSet , pero nunca la conexión.
El sistema no usa un grupo de conexiones.
¿Hay alguna razón para no cerrar todo ( Connection , PreparedStatement y ResultSet )?
La documentación de Connection indica que extiende AutoCloseable. La documentación de AutoCloseable establece que una clase la amplía cuando es un "recurso A que debe cerrarse cuando ya no se necesita". Ofrece un método Close, y tu amigo debería usarlo.
ResultSet también extiende AutoCloseable , pero PreparedStatement no lo hace.
No hay una buena razón para esto, resultará en una aplicación muy frágil. Es fácil que una conexión a la base de datos quede obsoleta si hay un problema de red o si la base de datos no responde por un tiempo, y con la dependencia de una única conexión existente no hay recuperación sin reiniciar la aplicación.
Hay otros puntos malos en esto. Por ejemplo, normalmente las conexiones están sincronizadas, de modo que si una aplicación web con múltiples usuarios simultáneos se creara de esta manera limitaría la concurrencia de la aplicación. Pero la incapacidad de su aplicación para recuperarse de problemas transitorios es suficiente para que esto valga la pena.
Probablemente esté usando la misma conexión para hacer todo el procesamiento de SQL. Esa no es una mala técnica; pero, si no escribió el código para un apagado limpio, entonces puede ser difícil saber cuándo cerrar la única conexión.
Así que apostaría a que la lógica de este código es dejar que el proceso muera, dejar que el socket muera como resultado de eso, y luego dejar que la base de datos remota limpie la conexión. Funciona, sí? Es desagradable y un lugar donde los problemas pueden ocurrir fácilmente, sí.
La forma de solucionar esto es encontrar su ciclo principal. El que sigue corriendo Luego debe controlar el apagado poniendo la lógica de apagado justo después del ciclo de procesamiento principal. Finalmente, tendrá que System.exit(...) el código de todas las System.exit(...) .
Supongo que, como mencionaste que el código fue heredado, era Java 1.6 o inferior. En el 1.7 y más allá, puede cerrar implícitamente un Closeable cuando lo usa en la construcción del lenguaje de try with resources .