estratégia de cache Hibernate

Question

Como faço para decidir qual CacheConcurrencyStrategy de usar?

• NonstrictReadWriteCache,
• ReadOnlyCache,
• ReadWriteCache,
• TransactionalCache.

Eu li https: //www.hibernate. org / hib_docs / v3 / API / org / hibernate / cache / CacheConcurrencyStrategy.html , mas não explica em detalhes o suficiente.

Answer 1

A documentação Hibernate faz um trabalho muito bom em defini-los:

19.2.2. Estratégia: somente leitura

Se seu aplicativo precisa de ler, mas Não modifique, instâncias de uma persistente classe, um cache somente leitura pode ser usado. Este é o mais simples e ideal executar a estratégia. É mesmo seguro para o uso em um cluster.

19.2.3. Estratégia: leitura / gravação

Se o aplicativo precisa de atualização dados, um cache de leitura-escrita pode ser apropriada. Esta estratégia de cache nunca deve ser usado se serializável nível de isolamento transação é requeridos. Se o cache é usado em uma ambiente JTA, você deve especificar o propriedade hibernate.transaction.manager_lookup_class e nomeando uma estratégia para a obtenção de o TransactionManager JTA. em outra ambientes, você deve garantir que a transação é concluída quando Session.close() ou Session.disconnect() é chamado. Se vocês quer usar esta estratégia em um cluster, você deve garantir que o implementação de cache subjacente travamento suportes. A built-in de cache fornecedores não suportam bloqueio.

19.2.4. Estratégia: não estrito leitura / gravação

Se o aplicativo apenas ocasionalmente precisa atualizar dados (ou seja, se é extremamente improvável que dois transações iria tentar atualizar o mesmo item em simultâneo), e rigoroso isolamento da transação não é necessária, um cache não estrito-read-write pode ser apropriada. Se o cache é usado em uma ambiente JTA, você deve especificar hibernate.transaction.manager_lookup_class. Em outros ambientes, você deve garantir que a transação é concluída quando Session.close() ou Session.disconnect() é chamado.

19.2.5. Estratégia: transacional

A estratégia de cache transacional fornece suporte para totalmente provedores de cache transacionais, como JBoss TreeCache. cache de tal só pode ser usado em um ambiente JTA e você deve especificar hibernate.transaction.manager_lookup_class.

Em outras palavras:

• Read-only: útil para dados que são ler com freqüência, mas nunca atualizado (dados por exemplo referenciais como países). É simples. Tem as melhores performances de todos (obviamente).

• Leitura / Gravação: desejável se as suas necessidades de dados a ser atualizado . Mas ele não fornece um href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#SERIALIZABLE" rel="noreferrer"> SERIALIZABLE nível de isolamento leituras fantasmas pode ocorrer (você pode ver no final de um algo transação que não estava lá no início). Ele tem mais sobrecarga do que só de leitura.

• não estrito leitura / gravação: Como alternativa, se é improvável dois tópicos transação separada poderia atualizar o mesmo objeto, você pode usar a estratégia de leitura não estrito-write. Ele tem menos sobrecarga de leitura e escrita. Este é útil para dados que são raramente atualizados .

• Transactional: Se você precisa de um totalmente transacional cache. Apenas adequado em um ambiente JTA.

Assim, escolher a estratégia certa depende do fato de que os dados estão sendo atualizados ou não, a frequência de atualizações e o nível de isolamento necessário. Se você não sabe como responder a estas perguntas para os dados que você deseja colocar em cache, talvez pedir algum apoio de um DBA.

Answer 2

READ_ONLY: Usado apenas para entidades que nunca mudam (exceção é lançada se uma tentativa de atualizar uma entidade como é feito). É muito simples e performance. Muito apropriado para alguns dados de referência estática que não mudam.

NONSTRICT_READ_WRITE: Cache é atualizado após uma transação que mudou os dados afetados foi cometido. Assim, a consistência forte não está garantida e há uma pequena janela de tempo no qual dados antigos podem ser obtidos a partir do cache. Este tipo de estratégia é adequada para casos de uso que podem tolerar consistência eventual.

READ_WRITE: Esta estratégia garante consistência forte que atinge usando bloqueios 'soft': Quando uma entidade em cache é atualizado, um bloqueio suave é armazenado em cache para essa entidade, bem como, o que é liberado após a transação é confirmada. Todas as transações simultâneas que acesso entradas locked-macios irá buscar os dados correspondentes diretamente do banco de dados.

TRANSACTIONAL: alterações de cache são feitas em transações XA distribuídos. Uma mudança em uma entidade em cache ou é confirmada ou revertida em ambos os banco de dados e de cache na mesma transação XA.

Answer 3

Reading API Docs é coisa boa, mas você também deve ler a documentação (sua incrível) também, cache de segundo nível -. Estratégias

Answer 4

1. Transactional -. Use esta estratégia para leitura na sua maioria de dados onde é fundamental para evitar que dados obsoletos em transações concorrentes, no caso raro de uma atualização

2. leitura e escrita -. Mais uma vez usar esta estratégia para leitura na sua maioria de dados onde é fundamental para evitar que dados obsoletos em transações concorrentes, no caso raro de uma atualização

3. não estrito-read-write - Esta estratégia faz nenhuma garantia de coerência entre o cache eo banco de dados. Use esta estratégia se os dados quase nunca muda e uma pequena probabilidade de dados obsoletos não é uma preocupação crítica.

4. Read-only - A estratégia de simultaneidade adequado para dados, que nunca muda. Use-o apenas para dados de referência.

Espero que isso limpa a sua dúvida!