Gerenciamento de conexões de banco
-
Pessoal,
Alguém ja teve problema com o gerenciamento de conexões no maker (utilizando um pool de conexões)?
Após atualizar para o Maker 5 notei que a aplicação tem aberto mais conexões que o necessário, bem como uma grande quantidade de cursores.Avaliando o código da função "Abrir Consulta" observei que o ResultSet, o PreparedStatement e a Connection não são fechadas explicitamente. Aparentemente o ResultSet é adicionado em uma lista ("openedResultSetList") para tratativas futuras.
Alguém sabe dizer quais seriam essas tratativas em cima desse objeto "openedResultSetList"?
Se os objetos de apoio são devidamente fechados? E se talvez essa não seria uma possível causa do consumo desnecessário dos recursos de banco? -
Boa tarde Nunes
Quando se utiliza um pool de conexões no Maker 5 e ocorre consumo excessivo de conexões e cursores no banco de dados, é fundamental compreender como a plataforma gerencia esses recursos internamente para mitigar problemas. O Maker, por meio do mecanismo openedResultSetList, controla instâncias abertas de ResultSet, gerenciando a abertura e o fechamento desses recursos de forma explícita. Contudo, se os recursos não forem liberados corretamente, podem ocorrer vazamentos que impactam diretamente o desempenho da aplicação e do banco.
Para evitar tais problemas, é essencial garantir o fechamento de Connection, PreparedStatement e ResultSet logo após seu uso. Caso o Maker não faça isso automaticamente ou de forma eficiente, pode ser necessário implementar lógicas que assegurem o fechamento manual desses recursos. Além disso, recomenda-se a revisão de logs e métricas do banco de dados para identificar possíveis vazamentos, bem como o uso de ferramentas de monitoramento que ajudem a detectar conexões não encerradas ou cursores excessivamente utilizados.
A configuração adequada do pool de conexões também desempenha um papel crucial na gestão eficiente de recursos. Parâmetros como o número máximo de conexões permitidas (maxConnections), tempo de espera (timeout) e período de inatividade (idleTime) devem ser revisados para atender às demandas da aplicação sem sobrecarregar o banco de dados. Além disso, ao realizar atualizações para o Maker 5, é importante revisar fluxos e scripts existentes para garantir que não dependam de práticas obsoletas ou comportamentos que possam ter sido alterados na nova versão.
Por fim, a adoção de boas práticas, como o uso de blocos try-with-resources ou estruturas equivalentes, assegura o fechamento automático de recursos. O monitoramento constante do ciclo de vida das operações de banco de dados, com logs detalhados e métricas específicas, é igualmente essencial para evitar problemas recorrentes e otimizar o uso de conexões e cursores no Maker 5.
