¿Que hace este metodo?

Yeap, al parecer revisa si la conexión de base de datos es válida ejecutando la consulta "SELECT 1".

El código dice lo siguiente:

Parece que se intenta usar para ver si una conexión es válida antes de ejecutar algún comando, pero este esfuerzo es inútil.

Lo que sucede es que usando este método, siempre se harán 2 viajes al servidor en vez de una ( una para ver si sirve y otra para ejecutar el comando en si mismo), y aunque parezca que es poco lo que hace, también es innecesario.

Peor aún, no hay forma de garantizar que una conexión que devolvió true como resultado de este método, no sea inválida al intentar usarlo.

Lo mejor es simplemente usar la conexión y manejar la excepción si la hubiera.

  no necesariamente hace un viaje a la base de datos. De hecho muy probablemente te devuelva el valor de una bandera, o revise si todavía tiene un socket abierto o algo así, pero no va a ir a la base de datos (no le tengas mucha fe a ese método porque luego no es tan confiable; devuelve   si ya invocaron   en esa conexión). Si la conexión ya fue cerrada previamente, la verificación termina en ese método.

La segunda invocación de SELECT 1 es para verificar que la conexión sigue arriba realmente (porque puede que   diga   pero la base de datos se cayó o se perdió la conexión de red o algo y entonces realmente ya no hay una conexión física al DBMS).

Esto es algo que por ejemplo los pools de conexiones a base de datos ya hacen por ti. Por ejemplo DBCP tiene un validationQuery que si lo defines, va a ejecutar cuando crea conexiones nuevas y también antes de prestarlas (incluso hay otro query para validar las conexiones cuando se las devuelven). c3p0 no tiene un query de validación configurable, sino que tiene una tabla de pruebas que debes definir en tu base de datos porque se hace una consulta a la misma para validar las conexiones (eso me parece más invasivo que permitir configurar un query para consultar la versión o la fecha actual, etc). BoneCP también tiene algo similar a DBCP. De modo que si usas un pool de conexiones, el método de validar conexión es completamente innecesario.

  no, pero el   si lo hace y yo me refería a un viaje por cada vez que se ejecuta el método  

Si además de este código ( suponiendo que fuera parte de una aplicación ) se usa un pool de conexiones como el que mencionas, entonces se harán tres accessos en vez de dos.

El punto es, que es mejor usar un pool de conexiones. No me parece que chaina esté queriendo implementar uno, aunque quizá este código que encontró pertenezca a un pool de conexiones.

En otro foro estaba ya preguntando por pools de conexiones, antes de este post. De hecho en el otro post mencionó esta función pero no había puesto el código, sólo mencionó que era para validar que la conexión no fuera null y por eso yo en broma le dije que era una función "enterprise" de esas tipo  . Pero bueno ya la puso aquí en vez de ponerla como comentario en el post original y vemos que hace algunas cosas adicionales, que si estás manejando un DataSource normal pues sí puede ser útil pero si usas un pool de conexiones, la función es redundante porque ya estas validaciones las hace el mismo pool.

Regresa un 1 Y siempre va aregresar un 1 Saludos!

Lo mejor como dice Oscar es lanzar el comando y mandar la excepcion, a proposito se que es una buena idea usar pool de conexiones, pero no siempre se puede, por poner un ejemplo algunas bases de datos relacionales manejan un costo por conexion, si solo podemos por cuestiones de $$$ tener una conexion abierta entonces el pool no tendria caso, es por eso que pueden existir este tipo de metodos para validar si tenemos la conexion activa, el problema es que connection.isClosed() puede llegar a retornar falsos positivos por esa misma razon se hace el SELECT 1, para que en caso que no se pueda ejecutar el query obtener la excepcion y retornar false, sin embargo creo que hacer este query es costoso y no garantiza que el siguiente query a ejecutar (es decir el que realmente queremos ejecutar) no vaya a fallar, por es mejor manejarlo por excepcion.

Si solamente te permiten tener una conexión abierta, entonces puedes tener un pool de una sola conexión. De esa manera siempre vas a tener la conexión ya abierta, en vez de crear, destruir, crear, destruir... y si por alguna razón se cae esa conexión, el pool se encargará de restablecerla.

Además, si solamente puedes tener una conexión, con el pool te aseguras de que realmente sólo uses una, porque si empiezas a meter Threads en tu aplicación, puedes llegar a la situación en que 2 threads quieren acceso a la base de datos; si usas el patrón crear-destruir entonces vas a crear 2 conexiones, violando la restricción de usar solamente una; si tienes una conexión siempre abierta, vas a tener broncas cuando quieras hacer 2 cosas simultáneas con la misma conexión. El pool administra esa única conexión prestándosela a uno de los procesos y cuando el segundo la pida, tendrá que esperar a que el primero termine (y si se tarda mucho y rebasa el tiempo de espera definido en el pool, se arrojará una excepción).

Bueno todo depende de las dimensiones de la aplicacion, he puesto un ejemplo donde podria no ser necesario el pool, de acuerdo a la magnitud de la aplicacion, es cierto la cosa se complica si se agregan otros elementos, como multithreading puesto que entonces se tendria que sincronizar los recursos, es solo que el codigo de arriba podria no pertenecer a una aplicacion con esas caracteristicas, posiblemente solo sea un programa que haga algunas lecturas a ciertas tablas y despues inserte o updetee otras entonces utilizar y configurar un pool de conexiones para un aplicativo asi tal vez no valga la pena.

Si tienes un jefe que te prohíbe usar un pool, entonces no tiene ningún caso encontrar justificaciones técnicas para no usar un pool. Simplemente la razón es "mi jefe es un idiota" y ya, pero no tienes que autoconvencerte de que es lo mejor si sabes que no es así y que la única razón por la que no usas un pool es por una restricción artificial, no técnica, simplemente tu jefe sufre de un desorden de retraso mental narcisista.

Mmm puede ser el caso