Acceso a datos

Un servicio funciona perfectamente durante semanas y, un martes por la tarde, se queda congelado. Ningún error, ningún pico de carga: simplemente todas las peticiones esperando, indefinidamente. El diagnóstico casi siempre es el mismo: una ruta de código toma prestada una conexión del pool y nunca la devuelve, porque se produjo una excepción entre la toma y la liberación. Tras unos cientos de ocurrencias, el pool queda vacío y cada nueva petición espera una conexión que no va a volver nunca.

El otro gran fallo de esta capa es la inyección SQL, y casi siempre ocurre por la misma razón: alguien ha construido una consulta concatenando cadenas porque la parametrización no funcionaba para su caso: un nombre de columna dinámico, una cláusula IN de tamaño variable, una ordenación configurable. Estos tres casos tienen soluciones limpias, y esta lección te las ofrece. El hilo conductor: una conexión se toma prestada y se devuelve siempre, y un valor procedente del cliente nunca pasa a formar parte del texto de una consulta.

El pool de conexiones

Abrir una conexión PostgreSQL cuesta varios milisegundos: handshake TCP, autenticación, creación de un proceso servidor en la base de datos. Un pool mantiene un conjunto de conexiones abiertas y las va prestando.