Cache Second Level

Entusiasta Java Membro desde: 11/02/2009 22:39:39 Mensagens: 18 Offline

Ae galera, queria pedir uma ajuda a voces, como eu posso ativar o cache de segundo nivel no JPA, java fiz a configuração abaixo no meu persistence.xml, mais nao esta funcionando.

Atenciosamente.

João Victor.

Ola Joao Victor.
Ja anotou suas entidades escolhidas com @Cache? O que esta saindo no log e como sabe que nao esta funcionando?

abracos!

Entusiasta Java Membro desde: 11/02/2009 22:39:39 Mensagens: 18 Offline

Paulo Silveira wrote:Ola Joao Victor.
Ja anotou suas entidades escolhidas com @Cache? O que esta saindo no log e como sabe que nao esta funcionando?

abracos!

Ola Paulo Silveira, Desde ja agradeço a ajuda.

Fiz a anotação do Cache sim.

O que me leva a saber que não esta funcionando, habilitei a exeibição dos codigos sql no meu persistence.xml é toda hora, que acesso as mesmas paginas no meu projeto, que precisam de um select por exemplo, do mesmo select, ele é executado novamente, o mesmo select.

Não sei se estou fazendo alguma confusão, mais é issu que ta acontecendo.

Obrigado.

pode postar o codigo que esta disparando a query que se repete? voce etou ela dentro do cache? (setCacheable(true) na Query ou Criteria)? Poste tambem as entidades relacionadas. Voce esta usando a mesma sessionfactory correto?

Virtual Machine Man Membro desde: 29/08/2006 21:50:17 Mensagens: 523 Offline

Paulo Silveira wrote:Ola Joao Victor.
Ja anotou suas entidades escolhidas com @Cache? O que esta saindo no log e como sabe que nao esta funcionando?

abracos!

Pela documentação das estratégias, não consegui compreender direito... :S ou está meio vago ou não compreendo bem aquele dialeto

Simplificando normalmente vejo nos exemplos o uso da estratégia:
@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)

Mas lendo lá no site a que mais parece se encaixar nos CRUD mais básico é a TRANSACTIONAL,,, ou não?

Documentação no site:
20.2.2. Strategy: read only

If your application needs to read, but not modify, instances of a persistent class, a read-only cache can be used. This is the simplest and optimal performing strategy. It is even safe for use in a cluster.

20.2.3. Strategy: read/write

If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class and naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called. If you want to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not support locking.

20.2.4. Strategy: nonstrict read/write

If the application only occasionally needs to update data (i.e. if it is extremely unlikely that two transactions would try to update the same item simultaneously), and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called.

20.2.5. Strategy: transactional

The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache can only be used in a JTA environment and you must specify hibernate.transaction.manager_lookup_class.

Notícias, artigos e o maior fórum brasileiro sobre Java