Egyidejűségi stratégiák
Miután engedélyezte a második szintű gyorsítótárat a hibernált módban, el kell magyaráznia a hibernáltnak, hogy mely entitásobjektumokat szeretnénk gyorsítótárba helyezni, és hogyan.
Ehhez a Hibernate egy speciális megjegyzéssel rendelkezik az entitásosztályokhoz - @Cache . Példa:
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
Ezt a megjegyzést minden olyan entitás entitáshoz meg kell írni, amelyhez a második szintű gyorsítótárat szeretnénk használni. Példa:
@Entity
@Table(name = "employee")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Employee {
@Id
private Integer id;
private Set<Task> tasks;
}
A hibernálás 4 lehetséges hozzáférési stratégiával rendelkezik egy gyorsítótárazott entitáshoz, ha az különböző szálakról érhető el:
- csak olvasható
- ír olvas
- nem szigorú írás-olvasás
- tranzakciós
Csak olvasható . Az adatoknak megfelelő párhuzamossági stratégia, amely soha nem változik. A Hibernate ezeket az objektumokat egyszerűen a memóriájában tárolja. Csak referencia adatokhoz használja.
Az adatbázisok sok információt tárolnak, amelyek soha nem változnak. Például egy táblázat listát tart azokról az eseményekről, amelyeket csak hozzáadnak, de soha nem módosítanak vagy távolítottak el. Ha ezzel a táblázattal hibernált állapotban kell dolgoznia, akkor a csak olvasható gyorsítótárazási stratégia megfelelő lesz.
Írni-olvasni (olvasni-írni). Ezt a stratégiát elsősorban olvasható adatok esetén használja. A Hibernate azonban nyomon követi az adatok megváltoztatására tett kísérleteket, bár arra számít, hogy ezek nagyon ritkák.
Főleg azokat az objektumokat kell gyorsítótárazni, amelyek ritkán változnak, és gyakran olvasnak/kérnek. Ha vannak ilyen objektumai, akkor az írási-olvasási stratégiát kell használnia hozzájuk.
Nem szigorú írás-olvasás . Ez a stratégia nem garantálja a konzisztenciát a gyorsítótár és az adatbázis között. Használja ezt a stratégiát, ha az adatok szinte soha nem változnak, és az elavult adatok kis esélye nem kritikus probléma.
Az írási-olvasási stratégiától eltérően ez a stratégia azt feltételezi, hogy a változtatható adatok nincsenek zárolva az olvasáshoz. Ez azt eredményezheti, hogy az objektum egyik helyen megváltozik, míg egy másik helyen valaki a régi verziót olvassa.
Például egy felhasználó megváltoztatta a megjegyzését, de a többi felhasználó egy ideig még mindig látja a régi verzióját. Ha ez nem jelent problémát az Ön számára, akkor használja a nonstrict-olvasás-írás stratégiát.
Tranzakciós . Használja ezt a stratégiát elsősorban csak olvasható adatokhoz, ahol fontos az egyidejű tranzakciók során az elavult adatok megelőzése a frissítések ritka alkalmával.
Adatok tárolása a gyorsítótárban
Egy másik fontos részlet a második szintű gyorsítótárral kapcsolatban, amelyet érdemes megjegyezni, hogy a Hibernate nem tárolja magukat az osztályok objektumait. Az információkat karakterláncok, számok stb. tömbjeként tárolja.
Az objektumazonosító pedig mutatóként működik erre az információra. Elméletileg ez olyan, mint egy térkép, amelyben az objektum azonosítója a kulcs, az adattömbök pedig az értéket. Így képzelheted el:
1 -> { "Ivanov", 1, null , {1,2,5} }
2 -> { "Petrov", 2, null , {1,2,5} }
3 -> { "Sidorov", 3, null , {1,2,5} }
Ami nagyon ésszerű, ha figyelembe vesszük, hogy az egyes objektumok mennyi extra memóriát foglalnak el.
A fentieken kívül ne feledje, hogy az Entity osztály függőségei szintén nincsenek alapértelmezés szerint gyorsítótárazva. Például, ha figyelembe vesszük a fenti, Employee osztályt , akkor a lekéréskor a feladatgyűjtemény az adatbázisból lesz lekérve , nem pedig a második szintű gyorsítótárból .
Ha a függőségeket is gyorsítótárba szeretné helyezni, akkor az osztálynak így kell kinéznie:
@Entity
@Table(name = "employee")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Employee {
@Id
private Integer id;
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
private Set<Task> tasks;
}
És az utolsó részlet - a második szintű gyorsítótár olvasása csak akkor történik meg, ha a kívánt objektum nem található az első szintű gyorsítótárban.
CacheMode
A hibernálás nagyon rugalmas gyorsítótárkezelést tesz lehetővé. Beállíthatja a gyorsítótár módot minden egyes munkamenethez vagy akár minden adatbáziskéréshez.
Öt ilyen mód létezik:
- KAP
- FIGYELMEN KÍVÜL HAGYNI
- NORMÁL
- PUT
- FRISSÍTÉS
Az alábbi táblázat leírja munkájukat:
CacheMode | Leírás |
---|---|
KAP | Az adatok beolvasásra kerülnek a gyorsítótárból, de nem adják hozzá. |
FIGYELMEN KÍVÜL HAGYNI | A munkamenet nem lép interakcióba a gyorsítótárral. |
NORMÁL | Az adatok beolvasása a gyorsítótárból történik, és hozzáadásra kerül. |
PUT | Az adatok soha nem kerülnek ki a gyorsítótárból, hanem hozzáadódnak hozzá. |
FRISSÍTÉS | Az adatok soha nem kerülnek ki a gyorsítótárból, hanem hozzáadódnak hozzá. Ebben a módban a hibernate.cache.use_minimal_puts beállítás is használatos. |
Példa a gyorsítótár mód beállítására egy munkamenethez:
session.setCacheMode(CacheMode.GET);
Employee director = session.createQuery("from Employee where id = 4").uniqueResult();
És egy példa a munkamenet és a kérés módjának beállítására:
session.setCacheMode(CacheMode.GET);
Query query = session.createQuery("from Employee where id = 4");
query.setCacheMode(CacheMode.IGNORE); // Ignore cache work for this request
Employee director = query.uniqueResult();