Entendendo o Hibernate Cache em detalhes

Trabalhar com Cache pode ser uma dor de cabe�a at� certo ponto, quando voc� n�o entende exatamente o que est� sendo feito. Muita das vezes, para tentar aumentar a produtividade de um projeto e entreg�-lo mais r�pido, voc� acaba apenas copiando configura��es de cache da internet, mesmo sem entender o que elas fazem e por onde passam.

O problema de trabalhar de forma mec�nica, sem entender o que est� sendo feito � quando ocorrem problemas e voc� n�o sabe nem por onde come�ar a an�lise.

Este artigo tratar� de um conceito muito discutido, mas que tamb�m traz diversas d�vidas e acaba tornando-se complexo quando n�o entendido de forma correta, o Hibernate Cache. Estudaremos aqui as tr�s formas de cache que o Hibernate utiliza: Cache do N�vel L1, QueryCache e Cache do N�vel L2.

O que � Cache e porque utilizar

Antes de iniciar explicando conceitos mais t�cnicos sobre configura��es e comportamentos de Cache no Hibernate, � essencial que voc� entenda porque est� fazendo isso e n�o simplesmente porque fica mais �bonito� ou porque todo mundo usa.

Sendo mais generalista, o conceito de Cache, na computa��o como um todo, veio para aumentar a performance de tarefas, diminuindo o acesso ao I/O (Dispositivos de Entrada e Sa�da, como o HD). O Cache de dados em mem�ria (mem�ria cache), evita que o processador tenha que acessar o HD (Hard Disk) toda vez que precisa de alguma informa��o para realizar c�lculos na ULA (Unidade L�gica e Aritm�tica), por exemplo. Depois de um certo tempo esses dados s�o removidos da cache para que novos entrem (pois a cache n�o � infinita, como j� imagin�vamos). � por isso que ao acessar pela primeira vez um programa no seu sistema operacional ele demora muito mais do que na segunda vez.

O conceito de Cache no Hibernate n�o foge a regra. O Hibernate realiza Cache dos dados vindos do banco de dados para evitar acessos desnecess�rios ao banco, pois acessar ao banco � muito mais custoso do que acessar a mem�ria, pois o acesso ao banco depende de diversos fatores tais como: disponibilidade da rede, velocidade de tr�fego da rede, mecanismos de busca otimizados no banco de dados e etc. Tudo isso pode fazer com que uma simples consulta torne-se uma grande dor de cabe�a.

A fun��o do Cache no Hibernate � em primeira inst�ncia acessar a base recuperando os dados solicitados e gravando em Cache. J� na segunda vez esse acesso ser� direto em Cache, o que aumentar� muito a performance da aplica��o.

Hibernate Cache

Iremos agora explicar o funcionamento de cada uma das caches a partir desta se��o. � importante saber que para ter um melhor entendimento do funcionamento da Cache no Hibernate � necess�rio entender o funcionamento do ciclo de vida de um Session, ou seja, como ele � criado, at� quando ele permanece �vivo�, o que tem dentro dele e etc. Isso foge do escopo deste artigo.

Cache L1 ou First Level Cache

O Cache L1 est� ligado diretamente ao Session do Hibernate, ou seja, o Cache L1 funciona durante todo o ciclo de vida do objeto Session, consequentemente �nasce� e �morre� com ele. Pelo fato do Cache L1 ser interno a um objeto Session, ele n�o pode ser acessado de outros Sessions criados pelo Session Factory.

A Figura 1 explica o fluxo de funcionamento deste.

Temos aqui quatro objetos na Figura 1:

Database: Representa a figura do banco de dados.
First-Level Cache: Represente o Cache L1 do Hibernate.
Session Object: Representa a Sess�o atual do Hibernate.
Client: Representa o Cliente que solicitar� as requisi��es.

Perceba que o Cliente n�o se comunica com o Cache L1, ele apenas conhece a exist�ncia do Session e o mesmo comunica-se com o Cache L1. Quando o cliente solicita um objeto do banco de dados (atrav�s do Session), sempre este primeiro consulta o Cache L1 para verificar se este objeto j� foi carregado, evitando assim o acesso ao banco, caso contr�rio, ele ir� busc�-lo no banco e depois armazenar no Cache L1, assim na segunda vez que tentarmos retorn�-lo, n�o ser� mais feito acesso ao banco.

Vamos ver um exemplo disso atrav�s de um trecho de c�digo presente na Listagem 1.


//(1)Abre uma Session do Hibernate
Session session = HibernateUtil.getSessionFactory().openSession();
session.beginTransaction();
 
//(2)busca o departamento pelo primeira vez
DepartmentEntity department = (DepartmentEntity) session.load(DepartmentEntity.class, 
new Integer(1));
System.out.println(department.getName());
 
//(3)busca o mesmo departamento novamente
department = (DepartmentEntity) session.load(DepartmentEntity.class, new Integer(1));
System.out.println(department.getName());
 
session.getTransaction().commit();
HibernateUtil.shutdown();
 
Saida:
 
Hibernate: select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
DEPARTMENT department0_ where department0_.ID=?
Human Resource
Human Resource

Listagem 1. Exemplo Cache L1 em funcionamento

Temos acima tr�s pontos importantes que explicam com mais detalhes o fluxo da Figura 1.

No primeiro ponto � aberto um Session e o Cache L1 tamb�m j� � ativado automaticamente para esse novo Session.
No segundo ponto � feita a primeira busca do Departamento no banco de dados e como este objeto ainda n�o foi armazenado no Cache, uma consulta � disparada no banco de dados. Voc� pode ver isso atrav�s do log gerado pela Hibernate:
```
    select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
    DEPARTMENT department0_ where department0_.ID=?.
```
No terceiro e �ltimo ponto tentamos buscar novamente o mesmo Departamento no banco de dados, ent�o o Session busca ele no Cache L1 e como o mesmo j� foi armazenado l�, ele apenas � recuperado sem disparar uma nova consulta ao banco.

Lembre-se que o Cache L1 n�o � compartilhado em Sessions distintas, ou seja, o mesmo objeto Departamento para um SessionX � diferente para um SessionY. Vamos ver um exemplo na Listagem 2.


//(1) Abre uma Session
Session session1 = HibernateUtil.getSessionFactory().openSession();
session.beginTransaction();

//(1) Abre outra Session, diferente da primeira
Session session2 = HibernateUtil.getSessionFactory().openSession();
sessionTemp.beginTransaction();
try
{
   //(2) Busca o departamento pela primeira vez na SESSION 1
   DepartmentEntity department = (DepartmentEntity) session1.load(DepartmentEntity.class, 
   new Integer(1));
   System.out.println(department.getName());
    
   //(3) Busca o departamento novamente na SESSION 1
   department = (DepartmentEntity) session1.load(DepartmentEntity.class, new Integer(1));
   System.out.println(department.getName());
    
   //(2) Busca o departamento pelo primeira vez na SESSION 2
   department = (DepartmentEntity) session2.load(DepartmentEntity.class, new Integer(1));
   System.out.println(department.getName());
}
finally
{
   session1.getTransaction().commit();
   HibernateUtil.shutdown();
    
   session2.getTransaction().commit();
   HibernateUtil.shutdown();
}

Saida:

Hibernate: select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
DEPARTMENT department0_ where department0_.ID=?
Human Resource
Human Resource

Hibernate: select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
DEPARTMENT department0_ where department0_.ID=?
Human Resource

Listagem 2. Exemplo de Cache L1 Com 2 Sessions

O c�digo acima demonstra que ao tentarmos buscar o mesmo objeto em um Session diferente, o acesso ao banco � feito, pois ele n�o existe no Cache L1 desta Session.

Mas e se voc� quiser for�ar que um objeto seja buscado diretamente no banco de dados, mesmo que ele esteja em Cache, como fazer? A resposta � r�pida: removendo ele do Cache L1, assim voc� for�ar� o Session a consultar diretamente o banco de dados.

Existem dois m�todos dispon�veis no objeto Session que podem fazer essa tarefa: evict() e clear().

O evict remove apenas um objeto da Cache L1, ou seja, imagine que voc� tem dentro do Cache L1 cinco objetos de diferentes tipos, mas gostaria que apenas o objeto do tipo Departamento fosse consultado diretamente no banco, ent�o voc� faria um �evict� deste objeto, o que ia limp�-lo da Cache L1 e depois faria um �load� novamente.

O clear remove todos os objetos presentes no Cache L1, ou seja, se voc� tiver cinco objetos, os cinco ser�o removidos, for�ando a busca direta no banco na pr�xima vez que um load for realizado. Vamos ver um exemplo disso para ficar mais claro na Listagem 3.


Session session = HibernateUtil.getSessionFactory().openSession();
 session.beginTransaction();
 try
 {
     //busca o departamento pela primeira vez
     DepartmentEntity department = (DepartmentEntity) session.load(DepartmentEntity.class, 
     new Integer(1));
     System.out.println(department.getName());
      
     //busca o departamento pela segunda vez
     department = (DepartmentEntity) session.load(DepartmentEntity.class, new Integer(1));
     System.out.println(department.getName());
      
     //limpa o departamento do cache l1
     session.evict(department);
     //session.clear();
      
     //busca o departamento pela terceira vez, buscar� o mesmo no banco de dados
     //pois foi removido da CACHE L1
     department = (DepartmentEntity) session.load(DepartmentEntity.class, new Integer(1));
     System.out.println(department.getName());
 }
 finally
 {
     session.getTransaction().commit();
     HibernateUtil.shutdown();
 }
          
 Saida:
          
 Hibernate: select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
 DEPARTMENT department0_ where department0_.ID=?
 Human Resource
 Human Resource
 
 Hibernate: select department0_.ID as ID0_0_, department0_.NAME as NAME0_0_ from 
 DEPARTMENT department0_ where department0_.ID=?
 Human Resource

Listagem 3. Usando evict() e clear()

Vamos ver agora alguns pontos importantes que devem ser fixados sobre o Cache L1 antes de passamos para o pr�ximo tipo de Cache.

O Cache L1 � habilitado por padr�o no Hibernate e voc� n�o pode desabilit�-lo.
O objeto Session sempre consulta o Cache L1 antes de ir ao banco de dados.
O Cache L1 est� associado somente a um objeto Session, outros objetos n�o podem �enxerg�-lo�.
Quando um load � executado pela primeira vez, a consulta � direta no banco, pois o objeto n�o existe no Cache.

Query Cache

Agora veremos uma �extens�o� da Cache L1, o Query Cache. Perceba que todos os objetos da L1 foram carregados atrav�s do m�todo �load()�, dispon�vel no objeto Session, isso porque ele faz a consulta ao Cache L1 antes de ir no banco de dados.

Mas o �load()� s� nos � �til quando temos a chave/id do objeto em quest�o, caso contr�rio ter�amos que executar uma query atrav�s do comando �session.createQuery()� e voc� ter� uma grande surpresa: O Cache L1 n�o funcionar� para este caso.

Ao realizar o �createQuery()�, o mesmo vai direto no banco sem importa-se com o Cache L1, trazendo um grande problema: O Cache L1 torna-se in�til. Para contornar esse problema � que surgiu o Query Cache.

O Query Cache armazena no Cache L1 os ID's dos resultados retornados, ou seja, � como se voc� tivesse executando diversos �load()� em v�rios objetos. Vamos ver um exemplo na Listagem 4.


Session session = getSessionFactory().openSession();
  Transaction tx = session.beginTransaction();
  Query query = session.createQuery("from Person p where p.id=1");
  query.setCacheable(true);
  Iterator it = query.list().iterator();
  while (it.hasNext ()){
     Person p = (Person) it.next();
     System.out.println(p.getFirstName());
  }
  query = session.createQuery("from Person p where p.id=1");
  query.setCacheable(true);
  it = query.list().iterator();
  while (it.hasNext ()){
     Person p = (Person) it.next();
     System.out.println(p.getFirstName());
  }
  tx.commit();
  session.close();

Listagem 4. Usando Query Cache

O ponto de aten��o acima � a linha �query.setCacheable(true)� que diz que o resultado desta query deve ficar em cache.

Al�m de setar a query como �cacheable�, voc� precisa mudar uma configura��o do seu arquivo de configura��o do Hibernate, conforme a Listagem 5.


<property name="hibernate.cache.use_query_cache">true</property>

Listagem 5. Habilitando o Query Cache

Com esses dois pontos a sua aplica��o est� pronta para usar o Query Cache e evitar consultar demasiadas ao banco.

Cache L2 ou Second-Level Cache

Diferente do Cache L1, o Cache L2 est� dispon�vel para todos os objetos Sessions criados pelo SessionFactory. Imagine, por exemplo, que voc� tem uma tabela no banco de dados com as configura��es da aplica��o que dever�o ser mantidas durante todo o ciclo da mesma e nunca ser�o alteradas. Voc� pode utilizar o Cache L2 para manter essas configura��es dispon�veis a todas as outras Sessions, evitando que voc� precise consultar o banco cada vez que precisar de uma configura��o.

O Cache L2 est� ligado ao objeto SessionFactory e a todo seu ciclo de vida, ou seja, ele �nasce� e �morre� no mesmo momento deste.

Na Figura 2 percebemos que foi adicionada uma camada a mais de comunica��o entre o Cache L1 e o Banco, isso significa que o Cache L1 comunica-se com o Cache L2 e este faz a comunica��o com o banco de dados.

Ent�o seguindo o fluxo, ficaria: O Session consulta o Cache L1 que por sua vez consulta o Cache L2 que por sua vez retorna os dados ou vai ao banco realizar a consulta. Quando uma consulta � feita diretamente ao banco de dados, tanto o Cache L1 como o Cache L2 s�o atualizados.

Quando um objeto n�o existe no Cache L1 mas existe no Cache L2, este � replicado para o Cache L1, evitando uma consulta ao Cache L2. Ent�o pense um pouco o que aconteceria se um objeto existisse no Cache L1 e no Cache L2 e voc� fizesse um �session.evict(objeto)�.

A resposta �: O Cache L1 seria limpa, mas o Cache L2 n�o. Ent�o o mesmo seria novamente replicado do Cache L2 para o L1, evitando a consulta ao banco de dados. Neste caso ter�amos que chamar o �evict� da SessionFactory. Vamos ver como na Listagem 6.


public void evict2ndLevelCache() {
  try {
      Map<String, ClassMetadata> classesMetadata = sessionFactory.getAllClassMetadata();
      for (String entityName : classesMetadata.keySet()) {
          logger.info("Evicting Entity from 2nd level cache: " + entityName);
          sessionFactory.evictEntity(entityName);
      }
  } catch (Exception e) {
      logger.logp(Level.SEVERE, "SessionController", "evict2ndLevelCache", 
      "Error evicting 2nd level hibernate cache entities: ", e);
  }
}

Listagem 6. Limpando objeto do Cache L2

Limpamos o objeto do Cache L2, mas lembre-se que se ele existir ainda no Cache L1, o Cache L2 jamais ser� acessado. Sendo assim, se voc� deseja for�ar a consulta ao banco, dever� limpar do Cache L1 e do Cache L2.

Como falamos anteriormente, o Cache L2 est� no escopo do SessionFactory, o que faz com o mesmo seja acessado por todos os Sessions criados pelo SessionFactory (normalmente uma aplica��o tem apenas uma SessionFactory). Ent�o vejamos na Listagem 7 um exemplo de dois Sessions acessando o mesmo objeto que est� no Cache L2.


//Objeto � buscado pela primeira vez e carregado no Cache L1 e Cache L2
 DepartmentEntity department = (DepartmentEntity) session.load(DepartmentEntity.class, 
 new Integer(1));
 System.out.println(department.getName());
 
 //Buscamos o objeto novamente, ele � retornado pelo Cache L1 pois est� na mesma Session
 department = (DepartmentEntity) session.load(DepartmentEntity.class, new Integer(1));
 System.out.println(department.getName());
 
 //Limpamos o objeto da Cache L1
 session.evict(department);
              
 //Buscamos o objeto novamente, ele � copiado do Cache L2 para o Cache L1
 department = (DepartmentEntity) session.load(DepartmentEntity.class, new Integer(1));
 System.out.println(department.getName());
 
 //Buscamos o objeto novamente, por�m agora em uma nova Session. Ele � copiado do Cache L2 
 para o Cache L1
 department = (DepartmentEntity) anotherSession.load(DepartmentEntity.class, new Integer(1));
 System.out.println(department.getName());
 
 System.out.println(
 HibernateUtil.getSessionFactory().getStatistics().getEntityFetchCount());           
 //Prints 1
 System.out.println(
 HibernateUtil.getSessionFactory().getStatistics().getSecondLevelCacheHitCount());   
 //Prints 2
 
 Output: 1 2

Listagem 7. Dois Sessions acessando um objeto no Cache L2

Perceba que em nenhum momento limpamos o Cache L2, ent�o neste caso o objeto sempre ser� retornando do Cache L2, sem consulta ao banco.

O Cache L2 mais utilizado pelo Hibernate � o EhCache, que faz todo o papel descrito acima. Para configur�-lo basta adicionar o c�digo da Listagem 8 no seu arquivo de configura��o do Hibernate.


<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
<property name="hibernate.cache.use_second_level_cache">true</property>

Listagem 8. Habilitando EhCache

Pronto, nosso EhCache est� habilitado. Agora basta criamos um arquivo de configura��o para configurarmos os par�metros deste, o ehcache.xml. Veja a Listagem 9.


<ehcache>    
<cache
    name="com.somecompany.someproject.domain.Country"
    maxElementsInMemory="10000"
    eternal="false"
    timeToIdleSeconds="300"
    timeToLiveSeconds="600"
    overflowToDisk="true"
/>
</ehcache>

Listagem 9. ehcache.xml

Tecnologias:

Confira outros conte�dos:

Introdu��o ao JDBC

Novidades do Java

Teste unit�rio com JUnit

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Ronaldo Em 2015

Coment�rios nesta publica��o Escrever um coment�rio sobre conte�do

Rebeca Camilo

N�vel 14

Olá, tem algum artigo ou vídeo para eu consumir antes deste pra "entender o funcionamento do ciclo de vida de um Session, ou seja, como ele é criado, até quando ele permanece “vivo”, o que tem dentro dele e etc."?

há 10 meses

Rodolfo Gomes

DevMedia

Opa Rebeca, tudo bem?

Vc pode seguir por meio desta trilha de estudo neste guia do Hibernate

https://www.devmedia.com.br/guia/hibernate/38312#cache

Espero ter auxilaido

há 10 meses

Respondido em tempo real

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso