Jakie są bufory pierwszego i drugiego poziomu w Hibernate?

Jest całkiem dobre wyjaśnienie buforowania pierwszego poziomu na blogu Streamline Logic.

Zasadniczo buforowanie pierwszego poziomu odbywa się na podstawie sesji, gdzie jako buforowanie drugiego poziomu może być współdzielone w wielu sesjach.

Oto podstawowe Wyjaśnienie Hibernate cache...

Bufor pierwszego poziomu jest skojarzony z obiektem "session". Zakres obiektów cache jest sesji. Po zamknięciu sesji obiekty buforowane znikają na zawsze. Pamięć podręczna pierwszego poziomu jest domyślnie włączona i nie można jej wyłączyć. Gdy zapytujemy obiekt po raz pierwszy, jest on pobierany z bazy danych i przechowywany w buforze pierwszego poziomu powiązanym z sesją hibernate. Jeśli zapytamy ponownie ten sam obiekt o ten sam obiekt sesji, zostanie on załadowany z pamięci podręcznej i żadne zapytanie sql nie zostanie wykonane. Załadowany element może zostać usunięty z sesji za pomocą metody evict(). Następne wczytywanie tego elementu spowoduje ponowne wywołanie bazy danych, jeśli zostało usunięte przy użyciu metody evict(). Cała pamięć podręczna sesji może zostać usunięta za pomocą metody clear(). Usunie wszystkie elementy zapisane w pamięci podręcznej.

Pamięć podręczna drugiego poziomu jest inna niż pamięć podręczna pierwszego poziomu, która jest dostępna do użycia globalnie w zakresie fabrycznym sesji. pamięć podręczna drugiego poziomu jest tworzona w sesji zakres fabryczny i jest dostępny do użycia we wszystkich sesjach, które są tworzone przy użyciu danej fabryki sesji. Oznacza to również, że po zamknięciu fabryki sesji Cała powiązana z nią pamięć podręczna umiera, a Menedżer pamięci podręcznej również jest zamknięty. Ilekroć sesja hibernate próbuje załadować encję, najpierw szuka buforowanej kopii encji w buforze pierwszego poziomu (powiązanej z konkretną sesją hibernate). Jeśli buforowana Kopia encji jest obecna w buforze pierwszego poziomu, jest zwracana jako wynik Metoda ładowania. Jeśli w buforze pierwszego poziomu nie ma buforowanego elementu, to bufor drugiego poziomu jest wyszukiwany dla buforowanego elementu. Jeśli bufor drugiego poziomu ma buforowany obiekt, jest zwracany jako wynik metody load. Ale, przed zwróceniem encji, jest ona przechowywana w buforze pierwszego poziomu również tak, że następne wywołanie metody ładowania dla encji zwróci encję z bufora pierwszego poziomu i nie będzie potrzeby ponownego przechodzenia do bufora drugiego poziomu. Jeśli encja nie zostanie znaleziona w buforze pierwszego poziomu i drugiego poziom bufora również, wtedy zapytanie bazy danych jest wykonywane i encja jest przechowywana w obu poziomach bufora, przed powrotem jako odpowiedź metody load().

Pamięć podręczna pierwszego poziomu

Hibernate próbuje odłożyć kontekst uporczywości do ostatniej możliwej chwili. Jak wyjaśniłem w w tym artykule, strategia ta jest tradycyjnie znana jako transakcyjne write-behind.

Write-behind jest bardziej związany z flushingiem Hibernate niż z jakąkolwiek logiczną lub fizyczną transakcją. Podczas transakcji kolor może wystąpić wielokrotnie.

Spłukane zmiany są widoczne tylko dla aktualna transakcja bazy danych. Dopóki bieżąca transakcja nie zostanie zatwierdzona, inne równoczesne transakcje nie będą widoczne żadnych zmian.

Ze względu na pamięć podręczną pierwszego poziomu, Hibernate może wykonać kilka optymalizacji:

• statement batching
• zapobiegaj utraconym anomaliom aktualizacji

Pamięć podręczna drugiego poziomu

Odpowiednie rozwiązanie buforujące musiałoby obejmować wiele sesji Hibernate i dlatego Hibernate obsługuje dodatkowe pamięć podręczna drugiego poziomu.

Bufor drugiego poziomu jest związany z cyklem życia SessionFactory, więc jest niszczony tylko wtedy, gdy SessionFactory jest zamknięty (zazwyczaj gdy aplikacja jest wyłączana). Pamięć podręczna drugiego poziomu jest głównie zorientowana na encje, chociaż obsługuje również opcjonalne rozwiązanie buforowania zapytań.

Aby uzyskać więcej informacji, sprawdź ten artykuł .

Domyślnie NHibernate używa buforowania pierwszego poziomu, które jest oparte na obiekcie sesji. ale jeśli używasz środowiska wieloserwerowego, pamięć podręczna pierwszego poziomu może nie być zbyt skalowalna wraz z pewnymi problemami z wydajnością. dzieje się tak ze względu na fakt, że musi wykonywać bardzo częste podróże do bazy danych, ponieważ dane są rozprowadzane na wielu serwerach. innymi słowy, NHibernate zapewnia podstawową, nie tak zaawansowaną w procesie pamięć podręczną L1 po wyjęciu z pudełka. Jednak nie zapewnia funkcje, które rozwiązanie buforujące musi mieć znaczący wpływ na wydajność aplikacji.

Więc pytaniem wszystkich tych problemów jest użycie pamięci podręcznej L2, która jest powiązana z obiektami session factory. zmniejsza to czasochłonne podróże do bazy danych, dzięki czemu ostatecznie zwiększa czas reakcji aplikacji.

Pamięć Podręczna Pierwszego Poziomu

Obiekt sesji przechowuje dane bufora pierwszego poziomu. Jest domyślnie włączona. Dane pamięci podręcznej pierwszego poziomu nie będą dostępne dla całej aplikacji. Aplikacja może używać wielu obiektów sesji.

Second Level Cache

Obiekt SessionFactory przechowuje dane bufora drugiego poziomu. Dane przechowywane w pamięci podręcznej drugiego poziomu będą dostępne dla całej aplikacji. Ale musimy to wyraźnie włączyć.

W pamięci podręcznej drugiego poziomu pliki HBM domeny mogą mieć zmienny klucz i wartość false. Na przykład, W tej klasie domen część czasu trwania w ciągu dnia pozostaje stała jako prawda uniwersalna. Tak więc może być oznaczony jako niezmienny w całej aplikacji.