Caçando seus gargalos com o Hibernate Statistics

Programaticamente usamos o SessionFactory:

Passada etapa de configuração vamos ver um exemplo de ajuda que o hibernate statistics pode dar. Para o exemplo abaixo temos uma classe utilitária para facilitar a criação de Sessions e das Statistics:

O indicado nesses casos seria usar algum container de Injeção de Dependências para fazer este controle, mas esse é um outro assunto.

O caso abaixo é o exemplo Pessoa que possui uma lista de Telefone. Nesse código estamos simulando a criação de 10 pessoas e seus respectivos telefones. Porém se notarmos bem o código, estamos salvando primeiro o telefone e depois a pessoa. Essa ordem acabará gerando (dependendo do dialeto hibernate utilizado no banco) um update para cada par de Pessoa e Telefone que inserirmos, pois o hibernate ao salvar o telefone ainda não tem o id da pessoa para enviar no insert de telefone.

Com o Hibernate Statistics podemos conferir quantos updates foram disparados através do método getEntityUpdateCount e conferir se realmente estamos disparando as operações da maneira correta:

Ao rodar o código temos a saída "Updates disparados:10". Graças ao Hibernate Statistics foi fácil de ver esses updates a mais, sem ter de ficar verificando os enormes logs de queries que uma aplicação pode gerar. Para resolver essa pendência basta inverter a ordem dos saves que teremos 0 updates no hibernate statistics.

O código abaixo insere dez pessoas no banco:

Em uma execução normal teríamos todas as sessões fechadas sem problema algum, porém vamos simular um erro a cada 3 saves:

Agora vemos através do hibernate statistics que nosso try/catch está falho e que, caso algo saia errado, esquecemos de fechar a sessão no catch. O certo neste caso era fechar a sessão no bloco finally, evitando que por causa de esquecimento alguém não tenha fechado a sessão.

Agora o hibernate statistics mostrará que todas as sessões foram fechadas para esse caso. Vale lembrar que ainda devemos verificar se o close terminou com sucesso, eliminando as possibilidades de uma sessão ou transação permanecer aberta (em último caso, deve ser logado com prioridade).

Podemos até coletar informações sobre as transações, adicionando as linhas de código abaixo, mostrando a quantidade de transações totais e as que deram certo:

É de grande ajuda que os sistemas tenham uma página que possa mostrar algumas dessas informaçãoes a qualquer hora. Inclusive o hibernate tem um método que mostra no log um resumo de todas as estatísticas importantes, para ver esse imprimi-lo basta invocar logSummary da classe Statistics.

O Hibernate Statistics está cheio de métodos uteis, uma pequena lista dos principais:

• getEntity[Delete,Insert,Load,Update]Count():long serve para obter informações sobre os CRUD das entidades
• getQueryExecutionMaxTimeQueryString():String retorna a consulta mais demorada
• getQueryExecutionMaxTime():long retorna o tempo de execução da consulta mais demorada
• getSecondLevelCacheHitCount():long retorna quantas vezes o hibernate conseguiu a informação que queria através do cache
• getSecondLevelCacheMissCount():long retorna quantas vezes o hibernate teve que ir no banco buscar a informação que queria pois ela não estava no cache

Existem muitos outros métodos interessantes que podem ser conferidos no javadoc da classe Statistics. Suas informações vai te ajudar a decidir que queries devem ser reescritas, colocadas no second level cache, quais relacionamentos devem ser carregados em modo batch, etc.

Apenas as estatísticas do Hibernate não vão ajudar a resolver todos os problemas da aplicação, porém facilitará muito quando você tiver que achar pequenas falhas, inconsistências, lentidão e excessos na comunicação aplicação-banco. Monitorar muito bem sua aplicação é essencial, para não depender apenas de utilizar profilings e debuggers, que deveriam ser ferramentas apenas nos casos mais graves.