Was sind die Caches der ersten und zweiten Ebene im Ruhezustand?
Antworten:
1.1) Cache der ersten Ebene
Cache der ersten Ebene Wird immer dem Sitzungsobjekt zugeordnet . Der Ruhezustand verwendet diesen Cache standardmäßig. Hier wird eine Transaktion nach der anderen verarbeitet, dh eine Transaktion wird nicht viele Male verarbeitet. Hauptsächlich wird die Anzahl der SQL-Abfragen reduziert, die innerhalb einer bestimmten Transaktion generiert werden müssen. Das heißt, anstatt nach jeder in der Transaktion vorgenommenen Änderung zu aktualisieren, wird die Transaktion erst am Ende der Transaktion aktualisiert.
1.2) Cache der zweiten Ebene
Der Cache der zweiten Ebene wird immer mit dem Session Factory-Objekt verknüpft . Während der Ausführung der Transaktionen werden dazwischen die Objekte auf Session Factory-Ebene geladen, sodass diese Objekte für die gesamte Anwendung verfügbar sind und nicht an einen einzelnen Benutzer gebunden sind. Da die Objekte bereits in den Cache geladen sind, muss zu diesem Zeitpunkt keine Datenbanktransaktion durchgeführt werden, wenn ein Objekt von der Abfrage zurückgegeben wird. Auf diese Weise funktioniert der Cache der zweiten Ebene. Hier können wir auch den Cache auf Abfrageebene verwenden.
Zitiert von: http://javabeat.net/introduction-to-hibernate-caching/
Im Streamline Logic- Blog finden Sie eine ziemlich gute Erklärung für das Caching der ersten Ebene .
Grundsätzlich erfolgt das Caching der ersten Ebene pro Sitzung, wobei das Caching der zweiten Ebene von mehreren Sitzungen gemeinsam genutzt werden kann.
Hier einige grundlegende Erklärungen zum Cache im Ruhezustand ...
Der Cache der ersten Ebene ist dem Sitzungsobjekt zugeordnet. Der Umfang der Cache-Objekte ist der Sitzung. Sobald die Sitzung geschlossen ist, sind zwischengespeicherte Objekte für immer verschwunden. Der Cache der ersten Ebene ist standardmäßig aktiviert und kann nicht deaktiviert werden. Wenn wir eine Entität zum ersten Mal abfragen, wird sie aus der Datenbank abgerufen und im Cache der ersten Ebene gespeichert, der der Sitzung im Ruhezustand zugeordnet ist. Wenn wir dasselbe Objekt erneut mit demselben Sitzungsobjekt abfragen, wird es aus dem Cache geladen und es wird keine SQL-Abfrage ausgeführt. Die geladene Entität kann mithilfe der evict()Methode aus der Sitzung entfernt werden . Beim nächsten Laden dieser Entität wird erneut ein Datenbankaufruf ausgeführt, wenn sie mithilfe der evict()Methode entfernt wurde. Der gesamte Sitzungscache kann mithilfe der clear()Methode entfernt werden . Es werden alle im Cache gespeicherten Entitäten entfernt.
Der Cache der zweiten Ebene unterscheidet sich vom Cache der ersten Ebene, der für die globale Verwendung im Session Factory-Bereich verfügbar ist. Der Cache der zweiten Ebene wird im Bereich der Sitzungsfactory erstellt und kann in allen Sitzungen verwendet werden, die mit dieser bestimmten Sitzungsfactory erstellt wurden. Dies bedeutet auch, dass nach dem Schließen der Session Factory der gesamte damit verbundene Cache stirbt und der Cache-Manager ebenfalls geschlossen wird. Wenn eine Sitzung im Ruhezustand versucht, eine Entität zu laden, sucht sie an erster Stelle nach einer zwischengespeicherten Kopie der Entität im Cache der ersten Ebene (die einer bestimmten Sitzung im Ruhezustand zugeordnet ist). Wenn eine zwischengespeicherte Kopie der Entität im Cache der ersten Ebene vorhanden ist, wird sie als Ergebnis der Lademethode zurückgegeben. Wenn sich im Cache der ersten Ebene keine zwischengespeicherte Entität befindet, wird der Cache der zweiten Ebene nach der zwischengespeicherten Entität gesucht. Wenn der Cache der zweiten Ebene eine zwischengespeicherte Entität hat, wird diese als Ergebnis der Lademethode zurückgegeben. Aber, Vor dem Zurückgeben der Entität wird sie auch im Cache der ersten Ebene gespeichert, sodass beim nächsten Aufruf der Lademethode für die Entität die Entität aus dem Cache der ersten Ebene selbst zurückgegeben wird und nicht erneut in den Cache der zweiten Ebene gewechselt werden muss. Wenn die Entität nicht im Cache der ersten Ebene und auch im Cache der zweiten Ebene gefunden wird, wird die Datenbankabfrage ausgeführt und die Entität in beiden Cache-Ebenen gespeichert, bevor sie als Antwort von zurückgegeben wirdload() Methode.
Dies ist eine sehr häufige Frage, daher basiert diese Antwort auf diesem Artikel, den ich in meinem Blog geschrieben habe.
Cache der ersten Ebene
Der Ruhezustand versucht, den Persistenzkontext bis zum letztmöglichen Moment aufzuschieben. Wie ich in diesem Artikel erklärt habe , ist diese Strategie traditionell als Transaktions-Write-Behind bekannt.
Das Write-Behind bezieht sich eher auf das Leeren des Ruhezustands als auf logische oder physische Transaktionen. Während einer Transaktion kann der Flush mehrmals auftreten.
Die gelöschten Änderungen sind nur für die aktuelle Datenbanktransaktion sichtbar. Bis die aktuelle Transaktion festgeschrieben ist, ist keine Änderung für andere gleichzeitige Transaktionen sichtbar.
Aufgrund des Caches der ersten Ebene kann Hibernate mehrere Optimierungen vornehmen:
Cache der zweiten Ebene
Eine ordnungsgemäße Caching-Lösung müsste sich über mehrere Hibernate-Sitzungen erstrecken. Aus diesem Grund unterstützt Hibernate auch einen zusätzlichen Cache der zweiten Ebene.
Der Cache der zweiten Ebene ist an den SessionFactory-Lebenszyklus gebunden, sodass er nur zerstört wird, wenn der SessionFactorygeschlossen wird (normalerweise, wenn die Anwendung heruntergefahren wird). Der Cache der zweiten Ebene ist in erster Linie auf Entitäten ausgerichtet, unterstützt jedoch auch eine optionale Abfrage-Caching-Lösung.
Weitere Informationen finden Sie in diesem Artikel .
Standardmäßig verwendet NHibernate das Caching der ersten Ebene, das auf Sitzungsobjekten basiert. Wenn Sie jedoch in einer Umgebung mit mehreren Servern ausgeführt werden, ist der Cache der ersten Ebene möglicherweise zusammen mit einigen Leistungsproblemen nicht sehr skalierbar. Dies liegt an der Tatsache, dass sehr häufig Daten in die Datenbank übertragen werden müssen, da die Daten auf mehrere Server verteilt sind. Mit anderen Worten, NHibernate bietet einen einfachen, nicht so ausgefeilten In-Process-L1-Cache. Es bietet jedoch keine Funktionen, die eine Caching-Lösung haben muss, um einen nennenswerten Einfluss auf die Anwendungsleistung zu haben.
Die Frage bei all diesen Problemen ist daher die Verwendung eines L2-Caches, der den Session Factory-Objekten zugeordnet ist. Es reduziert die zeitaufwändigen Fahrten zur Datenbank und erhöht so letztendlich die Antwortzeit der App.
First Level Cache
Das Sitzungsobjekt enthält die Cache-Daten der ersten Ebene. Es ist standardmäßig aktiviert. Die Cache-Daten der ersten Ebene sind nicht für die gesamte Anwendung verfügbar. Eine Anwendung kann viele Sitzungsobjekte verwenden.
Cache der zweiten Ebene
Das SessionFactory-Objekt enthält die Cache-Daten der zweiten Ebene. Die im Cache der zweiten Ebene gespeicherten Daten stehen der gesamten Anwendung zur Verfügung. Aber wir müssen es explizit aktivieren.
In einem Cache der zweiten Ebene können Domänen-Hbm-Dateien vom Schlüssel veränderbar sein und den Wert false haben. In dieser Domänenklasse bleibt beispielsweise ein Teil der Dauer eines Tages als universelle Wahrheit konstant. Daher kann es anwendungsübergreifend als unveränderlich markiert werden.