Hibernate strategia di cache

Question

Come faccio a decidere quale CacheConcurrencyStrategy da usare?

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

https: //www.hibernate. org / hib_docs / v3 / api / org / hibernate / cache / CacheConcurrencyStrategy.html , ma non spiega in dettaglio sufficiente.

Answer 1

Il Hibernate documentazione fa un buon lavoro a definirli:

  

19.2.2. Strategia: leggere solo

     

Se l'applicazione ha bisogno di leggere, ma   Non modificare, le istanze di un persistente   di classe, una cache di sola lettura può essere utilizzato.   Questo è il più semplice ed ottimale   l'esecuzione di strategia. E 'ancora al sicuro   per l'utilizzo in un cluster.

     

19.2.3. Strategia: lettura / scrittura

     

Se l'applicazione ha bisogno di aggiornare   i dati, una cache di lettura-scrittura potrebbe essere   adeguata. Questa strategia di cache   non dovrebbe mai essere utilizzato se serializable   livello di isolamento delle transazioni è   necessario. Se la cache viene utilizzata in un   ambiente JTA, è necessario specificare il   proprietà   hibernate.transaction.manager_lookup_class   e la denominazione di una strategia per l'ottenimento   il TransactionManager JTA. In altro   ambienti, è necessario controllare che   la transazione è completata quando   Session.close() o   Session.disconnect() si chiama. Se tu   si desidera utilizzare questa strategia in un   cluster, è necessario assicurarsi che il   attuazione della cache sottostante   supporti di bloccaggio. La cache integrata   provider non supportano bloccaggio.

     

19.2.4. Strategia: lettura / scrittura

     

Se l'applicazione solo occasionalmente   deve aggiornare i dati (cioè se è   estremamente improbabile che due   transazioni avrebbero cercato di aggiornare il   stesso elemento contemporaneamente), e la rigorosa   isolamento delle transazioni non è richiesto,   una cache nonstrict-lettura-scrittura potrebbe essere   adeguata. Se la cache viene utilizzata in un   ambiente JTA, dovete specificare   hibernate.transaction.manager_lookup_class.   In altri ambienti, si dovrebbe   assicurarsi che l'operazione è   completato quando Session.close() o   Session.disconnect() si chiama.

     

19.2.5. Strategia: transazionale

     

La strategia di cache transazionale   fornisce il supporto per completamente   fornitori di cache transazionali come   JBoss TreeCache. Tale cache può solo   essere utilizzato in un ambiente JTA e si   deve specificare   hibernate.transaction.manager_lookup_class.

In altre parole:

• di sola lettura: Utile per i dati che è Leggi frequenti ma mai aggiornati (ad esempio dati referenziali, come i Paesi). È semplice. Ha le migliori prestazioni di tutti (ovviamente).

• lettura / scrittura: auspicabile che le vostre esigenze di dati per essere aggiornato . Ma non fornisce una SERIALIZABLE livello di isolamento , phantom legge si può verificare (si può vedere alla fine di una transazione qualcosa che non c'era alla partenza). Ha più in alto di sola lettura.

• nonstrict lettura / scrittura: In alternativa, se è improbabile due thread separati transazione potrebbe aggiornare lo stesso oggetto, è possibile utilizzare la strategia nonstrict-lettura-scrittura. Ha meno overhead di scrittura lettura. Questo è utile per i dati che sono raramente aggiornati .

• transazionale: Se avete bisogno di un completamente transazionale di cache. Adatto solo in un ambiente JTA.

Quindi, scegliere la giusta strategia dipende dal fatto che i dati vengono aggiornati o no, la frequenza degli aggiornamenti e il livello di isolamento richiesto. Se non si sa come rispondere a queste domande per i dati che si desidera mettere in cache, forse chiedere un certo sostegno da un DBA.

Answer 2

READ_ONLY: Usato solo per i soggetti che non cambiano mai (viene generata un'eccezione se un tentativo di aggiornare tale entità è fatto). E 'molto semplice e performante. Molto adatto per alcuni dati di riferimento statici che non cambiano.

NONSTRICT_READ_WRITE: Cache viene aggiornato dopo una transazione che ha cambiato i dati interessata è stato commesso. Così, consistenza forte non è garantita e v'è una finestra di tempo piccolo in cui i dati aggiornati possono essere ottenuti dalla cache. Questo tipo di strategia è adatto per i casi d'uso che possono tollerare l'eventuale coerenza.

READ_WRITE: Questa strategia garantisce la consistenza forte che raggiunge utilizzando blocchi 'morbidi': Quando un'entità cache viene aggiornata, un blocco morbido viene memorizzato nella cache per tale entità pure, che è rilasciato dopo che la transazione è impegnata. Tutte le transazioni simultanee che accedono voci morbide-locked preleveranno i dati corrispondenti direttamente dal database.

TRANSACTIONAL: modifiche cache vengono fatto in transazioni XA distribuite. Un cambiamento in un'entità cache è o commit o il rollback sia in database e la cache nella stessa transazione XA.

Answer 3

Reading Documentazione API è buona cosa, ma si dovrebbe anche leggere la documentazione (la sua impressionante) anche, secondo Livello cache -. Strategie

Answer 4

1. transazionale -. Utilizzare questa strategia per lettura per lo più dati in cui è fondamentale per evitare che i dati non aggiornati in transazioni concorrenti, nel raro caso di un aggiornamento

2. lettura e scrittura -. Anche in questo caso utilizzare questa strategia per lettura per lo più dati in cui è fondamentale per evitare che i dati non aggiornati in transazioni concorrenti, nel raro caso di un aggiornamento

3. nonstrict-lettura-scrittura - Questa strategia non fa alcuna garanzia di coerenza tra la cache e il database. Usare questa strategia, se i dati quasi mai cambia e una piccola probabilità di dati stantio non è motivo di seria preoccupazione.

4. di sola lettura - Una strategia concorrenza adatto per i dati, che non cambia mai. Usalo solo per i dati di riferimento.

Spero che questo cancella il tuo dubbio!