Acesso a dados

Um serviço funciona perfeitamente por semanas e, então, trava numa terça-feira à tarde. Nenhum erro, nenhum pico de carga: simplesmente todas as requisições esperando, indefinidamente. O diagnóstico quase sempre é o mesmo — um caminho de código pega uma conexão emprestada do pool e nunca a devolve, porque uma exceção ocorreu entre o empréstimo e a liberação. Depois de algumas centenas de ocorrências, o pool está vazio, e toda nova requisição espera por uma conexão que nunca voltará.

A outra grande falha dessa camada é a injeção de SQL, e ela quase sempre acontece pelo mesmo motivo: alguém montou uma consulta por concatenação de strings porque a parametrização não funcionava para o seu caso — um nome de coluna dinâmico, uma cláusula IN de tamanho variável, uma ordenação configurável. Esses três casos têm soluções limpas, e esta lição as apresenta. O fio condutor: uma conexão é emprestada e devolvida sempre, e um valor vindo do cliente nunca entra no texto de uma consulta.

O pool de conexões

Abrir uma conexão PostgreSQL custa vários milissegundos — handshake TCP, autenticação, criação de um processo servidor no lado do banco. Um pool mantém um conjunto de conexões abertas e as empresta.