Cum memorie cache de nivel secundar hibernează exemple - Blogul Anatoli Korsakov

Caching este o oportunitate oferită de cadrele ORM, care ajută utilizatorii pentru a atinge de mare viteză, și, în același timp, să se ajute singuri cadre pentru a reduce numărul de apeluri către baza de date. Hibernate oferă această opțiune pe două niveluri.

O dată, o dată în obiectul entitate cache-al doilea nivel este utilizat de-a lungul obiectului sessionFactory viata. și anume domeniul de aplicare al cache - toate programului nostru. Pentru a fi mai exact, modul în care configurați cache-ul, așa că ei înșiși și plumb. De asemenea, înseamnă că, în cazul în care fabrica închis sesiuni, întregul cache „mor“, asociat cu ea și managerul de cache este de asemenea oprit.

Spre deosebire de cache de nivelul întâi în al doilea nivel de cache-ul trebuie să includă în mod direct în setările Hibernate, și este realizat furnizor de o terță parte de bibliotecă cache.

Deci, înseamnă că, dacă aveți două instanțe fabrica de sesiune (aproximativ normală cu siguranță nu va fi la fel de dezvoltat), veți avea două cache-ul în managerul de aplicații, și puteți obține rezultate neașteptate.

In acest tutorial voi discuta conceptul de memorie cache al doilea nivel, și să dea exemple de utilizare. A doua parte puteți citi aici.

Dar, înainte de aceasta, voi explica conceptul de „invalidare“. Documentația este noțiunea comună de invalidare (invalidat) cache date vechi în cache-ul după cache mutat la această stare, el trebuie să fie curățată de date vechi prin eliminarea și re-actualizat cu valori noi, după actualizare, cache-ul devine valid (Validează) de stat.

Cum cache-al doilea nivel

Să scrie toate faptele:

1. primul nivel de cache cache-uri în primul rând entitate. dar suporta cache-ul de interogare opțional.
2. Ori de câte ori sesiune Hibernate încearcă să se încarce esența, primul loc unde va căuta este copia din cache a esenței cache la primul nivel (asociat cu sesiunea parțială).
3. În cazul în care copia din cache a entității este prezentă în primul cache de nivel, acesta va reveni ca rezultat al metodei de încărcare ().
4. În cazul în care nu a fost găsit în primul cache de nivel, cache-ul este căutat în al doilea nivel (dacă este activat).
5. În cazul în care al doilea nivel de cache a salvată în memoria cache entitate, acesta va reveni ca rezultat al metodei de încărcare (). Dar, înainte de a reveni esenta, acesta va rămâne în cache-ul de la primul nivel, precum și, astfel încât următorul apel la esența metodei de descărcare va reveni esența cache, în primul nivel și nu mai este nevoie pentru a căuta în cache-ul celui de al doilea nivel din nou.
6. În cazul în care entitatea nu a fost găsit în primul cache de nivel, nici în al doilea nivel de cache, cererea este executată în entitatea DB și să rămână în ambele cache-uri înainte de a reveni, ca urmare a sarcinii de asteptare ().
7. cache-Al doilea nivel ține evidența actualizărilor entității din cache. În cazul în care modificările au fost efectuate prin intermediul API Session.
8. În cazul în care un anumit utilizator sau un proces de a face modificări direct în baza de date, cache-ul celui de al doilea nivel există posibilitatea de a face upgrade la timp «timeToLiveSeconds» care acționează pentru regiunea cache. În acest caz, o idee bună este de a invalida întregul cache și pentru a permite Hibernate pentru a construi din nou memoria cache. Puteți utiliza următorul cod pentru a invalida întreaga cache-ul în al doilea nivel:

Interioarele de memorie cache

Fiecare entitate este stocată ca CacheEntry și fiecare entitate este convertit într-o stare hidratată pentru a crea o intrare în cache. In termeni Hibernate, hidratarea este atunci când JDBC ResultSet într-o matrice de valori brute:

Asta este, se stochează informații sub formă de matrice de siruri de caractere, numere și așa mai departe. D. și identificatorul de obiect servește un pointer la informații. Conceptual, este ceva de genul hartă, unde ID-ul obiectului - cheie, și fișiere de date - valoarea. Aproximativ o poate imagina ca acest lucru:

„Hidratată“ de stat este salvat în actualul context Persistența rulează ca un EntityEntry obiect. care încapsulează esența instantaneu, luate la momentul descărcării. Apoi, această stare este utilizat pentru:

• implicit mecanismul de „murdar“ de verificare care compară datele actuale împotriva esența instantaneul capturat în timpul ghetei
• cache-al doilea nivel, în care intrările cache sunt construite din această stare hidratată.

Operația inversă se numește deshidratare și copiază starea naturii în declarațiile INSERT și UPDATE.

Cum cache-ul de interogare (interogare cache)?

Memoria cache interogare este conceptual arata ca hash SiteMap, în cazul în care cheia servește compoziția textului și valorile parametrilor de interogare, iar valoarea Id-ul este o listă a entităților care sunt potrivite pentru:

Unele interogări nu returnează entității, în schimb se întorc numai valori primitive. În acest caz, valorile însele sunt stocate în memoria cache de interogare. Memoria cache de interogare este umplut atunci când o interogare JPQL / HQL în cache.

Cum sunt al doilea nivel de cache și cache-ul de interogare?

În cazul în care cererea se realizează rezultate anterioare stocate în memoria cache, interogarea SQL la baza de date nu va fi trimis. In schimb, interogarea rezultatele din cache-ul de interogare etanșeității și identificatorul entitate apoi în cache vor fi utilizate pentru a obține de la al doilea nivel de cache.

În cazul în care cache-al doilea nivel conține date pentru ID-ul, aceasta este esența unei deshidratant și să aducă înapoi. Dacă cache-al doilea nivel nu conține rezultatele pentru ID-ul, atunci interogarea SQL este executat pentru a încărca de la entitatea de bază de date.

Cum să activați și să configurați cache-al doilea nivel?

Primul pas este de a include dependența hiberneze-ehcache fișierul POM.

În mod implicit, cache-al doilea nivel este oprit și să-l activeze, avem nevoie pentru a seta următoarele proprietăți Hibernate:

sau configurare xml:

RegionFactory stabilește al doilea furnizor de cache de nivel, iar proprietatea hibernate.cache.region.factory_class câmp obligatoriu la expuse la valoarea proprietății hibernate.cache.use_second_level_cache adevărat.

Următorul pas este de a configura setările cache din regiunile fișierul-cache-config.xml, o descriere a setărilor este dată în a doua parte:

Pentru a activa nivelul entității cache, avem nevoie pentru a pune în jos rezumatul entității din cache:

Asociația poate fi, de asemenea, în cache cache-al doilea nivel, dar aceasta nu este activată în mod implicit. asociații Caching pentru care avem nevoie pentru a seta @Cache adnotare la asociația în sine:

JPA oferă, de asemenea adnotare @Cacheable, dar nu acceptă instalarea proprietăților strategiei de concurență la nivelul de esență.

Cum să utilizați cache-ul de interogare?

Interogările implicită de memorare în cache Hibernate folosește două cache internă:

• org.hibernate.cache.StandardQueryCache. Cache este utilizat în cazul în care nu sunt specificate în mod explicit în cerere, care numele regiunii / Cache folosit conține un rezultat de interogare stocate în memoria cache. În mod implicit, nu hibernează cache invalidează StandardQueryCache (SQC), t. E. Nu-l elimina atunci când devine caducă sau atunci când entitățile au fost făcute în manipularea cache-ul, de exemplu, să actualizeze sau să șteargă entitățile.
• org.hibernate.cache.UpdateTimestampsCache. Acesta conține marcajele de timp () marcajele de timp cele mai recente modificări tabele stocate în memoria cache. Este necesară pentru validarea rezultatelor, pe care a primit din cache-ul de interogare.

După configurarea cache-ul de interogare, nici o cerere nu este zakeshiruetsya implicit. Cererile trebuie să fie menționate în mod explicit, de exemplu:

Și un exemplu de cum pentru a marca interogarea criterii ca în cache:

(Vizitat 557 ori, 1 vizite azi)