O problema com os drivers JDBC é que uma conexão somente pode ser utilizada por uma thread de cada vez, senão uma thread poderia enviar uma consulta enquanto outra estivesse recebendo os resultados, o que causaria uma grande confusão.
O driver JDBC do PostgreSQL é seguro para threads. Conseqüentemente, não há necessidade do usuário se preocupar com algoritmos complexos para garantir que somente uma thread vai utilizar o banco de dados de cada vez, quando a aplicação utiliza várias threads.
Se uma thread tentar utilizar a conexão enquanto outra está utilizando, vai aguardar até que a outra thread termine a operação corrente. Se a operação for uma declaração SQL comum, a operação consiste em enviar a declaração e receber algum ResultSet (completo). Se for uma chamada fast-path (por exemplo, leitura de um bloco de um objeto grande) então consiste em enviar e receber o respectivo dado.
Esta forma é boa para aplicações e applets, mas pode causar problemas de desempenho com servlets. Havendo várias threads realizando consultas então todas elas, com exceção de uma, vão ficar aguardando. Para resolver este problema aconselha-se a criação de um pool de conexões. Sempre que uma thread precisa utilizar o banco de dados solicita a classe gerenciadora um objeto Connection. A classe gerenciadora entrega uma conexão livre para a thread e a marca como ocupada. Se não existir uma conexão livre disponível, então uma é aberta. Quando a thread terminar de utilizar a conexão vai devolvê-la para a classe gerenciadora, que vai fechá-la ou adicioná-la ao pool. A classe gerenciadora também pode verificar se a conexão ainda está viva, e removê-la do pool se estiver morta. O problema do pool de conexão é que aumenta a carga no servidor, porque uma nova sessão é criada para cada objeto Connection, por isso seu uso fica a critério do desenvolvedor ou dos requisitos da aplicação.
| Anterior | Principal | Próxima |
| Extensões do PostgreSQL à API JDBC | Acima | Pools de conexão e fontes de dado |