A második szintű gyorsítótár konfigurálása

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:

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();