Pool de conexiones

Una opción es depurar (debug) la aplicación. Y otra, dependiendo de la implementación del pool, es habilitar el registro ( ).

Ese método de obtener una conexión sólo es bueno tenerlo si lo vas a usar en try-with-resources, de otro modo es un antipatrón.

Y eso que dices de que quieres saber si una conexión ya se liberó para usarla y no sé qué, pues sólo es relevante si estás implementando un pool de conexiones, cosa que NO deberías hacer. Precisamente el pool de conexiones es el que se encarga de administrar las conexiones a la base de datos y si es necesario crear una nueva lo hará, o si es necesario dejarte esperando un rato primero para ver si se libera alguna otra lo hará, para que tú no tengas que preocuparte por nada de eso. Cuando invocas  , no te debe importar si se acaba de crear esa conexión o si ya estaba hecha desde antes; cuando la obtienes es porque está libre y nadie la va a usar mientras la tengas tú. Pero es muy importante que siempre le des   al final porque eso realmente no cierra la conexión sino que la devuelve al pool, por eso las debes usar de esta forma si es que vas a lidiar con conexiones de manera directa:

Eso que estás haciendo de invocar getConnectionDato() en un ciclo, lo único que estás causando es que obtienes 9 conexiones y solamente usas la última, y al final, solamente devuelves esa al pool, todas las demás siguen estando marcadas como ocupadas, aunque nunca las usaste. Eso se llama resource leak.

De hecho se esta implementando un pool de conexiones,
por ello la pregunta y gracias por aclararme algunos puntos. que tengo que corregir.

Usa commons DBCP o C3P0 o BoneCP, no implementes uno.

Si vas a “reinventar” la rueda, al menos, hazla bien. (1) No vaya a pasar lo siguiente:

1. Recomendable únicamente si esto tiene propósitos didácticos.

~~~

Tomare mucho en cuenta! sus respuestas y gracias! por el apoyo. ..