← Middleware: compreender e operar a cadeia
10 / 12 · 50 MIN

Pools JDBC e transações sob pressão

Relaciona orçamento de sessões, retenção de ligações e conclusão transacional com throughput útil.

Orçamento global de ligações

Um limite de pool pertence a um âmbito concreto. Antes de escalar, conta réplicas e pools independentes por datasource e inclui outros consumidores e reserva operacional. Quatro réplicas com dois pools de quinze permitem até 120 ligações, sem afirmar que todas estão abertas. O número configurado deve caber no orçamento acordado com a dependência. Open Liberty documenta parâmetros do connection manager, mas não deves copiar limites para WebSphere traditional sem confirmar produto e versão. Num exercício, apresenta a conta antes e depois da mudança e indica como validar capacidade e throughput sob carga representativa.

Aquisição, utilização e execução

Distingue tempo para obter uma ligação de tempo a utilizá-la e de execução SQL. Um timeout de getConnection em HikariCP indica espera de aquisição; não identifica automaticamente uma query lenta nem prova pool pequeno. Recolhe ocupação, pedidos à espera e distribuição de tempo de posse. Liga esses dados a stacks e sessões no mesmo intervalo. Se uma release aumenta retenção de ligações, aumentar o limite pode transferir a fila para a base de dados. Num exercício, escolhe as medidas que distinguem falta de capacidade de trabalho prolongado ou ligações não devolvidas.

Estado da sessão e espera

No exemplo PostgreSQL 18, state e wait_event descrevem dimensões diferentes. Uma sessão active pode estar à espera de lock; não se deve ler active como consumo contínuo de CPU. Identifica a query, a idade da transação, o bloqueador e a relação com o pedido da aplicação. Uma sessão idle in transaction mantém trabalho transacional aberto, podendo continuar a afetar outras operações. Antes de terminar sessões, delimita a população e consulta o responsável sobre efeitos e rollback. Uma lista de IDs sem contexto de negócio não é um plano de recuperação.

Concluir transações e devolver recursos

O ciclo de vida deve cobrir sucesso, erro e cancelamento. Em JDBC, define explicitamente commit ou rollback quando uma transação está ativa, antes de fechar; o resultado de close com transação pendente é dependente da implementação. Um caminho de exceção que não devolve a ligação pode consumir o pool gradualmente. Num exercício, revê o fluxo que falha depois de obter a ligação e identifica quem conclui a transação e liberta recursos. Verifica sob falha que o pool volta a ter capacidade e que o resultado da operação é conhecido, sem assumir sucesso apenas porque deixou de lançar exceções.

Limiar de leak e vida da ligação

Parâmetros com nomes semelhantes podem controlar mecanismos diferentes. Em HikariCP, o limiar de leak produz um aviso sobre tempo fora do pool; não comprova fuga permanente nem recuperação automática. Um relatório demorado pode ultrapassar esse limiar e ainda devolver corretamente a ligação. maxLifetime também não é um timeout de query: uma ligação em uso não é retirada por esse mecanismo enquanto está emprestada. Escolhe controlos adequados para aquisição, query e transação e confirma suporte do driver. Num exercício, associa cada sintoma à fase correta antes de propor uma alteração de configuração.

Aceitar capacidade pelo resultado útil

Uma mudança de pool deve ser avaliada na cadeia completa. Se a aquisição melhora mas os commits caem de 800 para 500 por segundo, o serviço pode ter piorado. Define antecipadamente throughput, latência, erros, limites da dependência e critério de reversão. Mantém carga e população comparáveis durante o teste. Se a causa é um lock retido durante uma chamada externa, avalia reduzir a secção transacional preservando consistência, em vez de acrescentar ligações que esperam pelo mesmo recurso. Entrega ao RUN valores efetivos, evidência dos gates, limitações e responsáveis pelas ações ainda pendentes.

NA PRÁTICA

Duplicar réplicas de quatro para oito, mantendo 20 ligações por pool, aumenta o teto de 80 para 160. Com orçamento de 150, a mudança exige rever o total e validar a dependência.

Armadilhas comuns

Pool local como orçamento global; timeout de aquisição como timeout SQL; aviso como libertação; close como conclusão garantida.

Tópicos relacionados: Investigar JVM, heap e pausas · Relacionar threads, pools e dependências · Operar TLS, certificados e configuração

Leva esta ideia contigo

Dimensiona a cadeia e corrige o ciclo de vida das ligações, verificando resultados antes de aumentar concorrência.

Criar conta

Referência: Connection Manager · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references