Aktueller Forschungsstand - JPA

This commit is contained in:
marcodn 2023-12-28 13:29:01 +01:00
parent 93ffa88aa6
commit 4b8159f412
2 changed files with 36 additions and 0 deletions

View file

@ -88,6 +88,42 @@ Größere Abweichung weißen häufig auf veraltete Statistiken hin.
\citep[60]{MüllerWehr2012}
Die JPA wird als First-Level-Cache in Java-EE-Anwendung gehandhabt.
Hierbei nehmen die Objekte einen von 4 Zuständen ein \citep[57]{MüllerWehr2012}.
Im \textbf{Transient} sind die Objekt erzeugt, aber noch noch in den Cache überführt worden.
Wenn Sie in den Cache überführt wwerden, nehmen sie den Zustand \textbf{Verwaltet} ein.
Für das löschen eines Objektes gibt es den Zustand \textbf{Gelöscht}, wodurch auch das Objekt
aus der Datenbank entfernt wird.
Als letzten Zustand gibt es noch \textbf{Losgelöst}, hierbei wird das Objekt aus dem Cache
entfernt, aber nicht aus der Datenbank.
Eine Menge von Objekten wird als \textit{Persistenzkontext}. Solange die Objkte dem Persistenzkontext
zugeordnet sind, also den Zustand Verwaltet besitzen, werden diese auf Änderungen überwucht
um diese am Abschluss mit der Datenbank zu syncronisieren. In der Literatur nennt man das
\textit{Automatic Dirty Checking} \citep[61]{MüllerWehr2012}.
In den Java-EE-Anwendungen wird der Persistenzkontext für die Anfragen vom Application-Server
bereitgestellt. Hierfür werden Application-Server wie GlassFish\textbf{!!!URL!!!} genutzt,
um die Verwendung eines Pools von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}.
Hiermit kann die Anzahl der Verbindung geringer gehalten werden als die Anzahl der Benutzer die
an der Anwendung arbeiten.
Zusätzlich werden die Transaktionen über Stateful Session-Bean (SFSB) gehandbabt, die automatisch
vor dem Aufruf erzeugt und danach wieder gelöscht werden. Dies hat allerdings den Nachteil,
dass der Persistenzkontext sehr groß werden kann, wenn viele Entities in den Persistenzkontext
geladen werden. Da dies häufig zu Speicher- und damit Performan-Problemen \citep[79]{MüllerWehr2012}
führt, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem Persistenzkontext
lösen, oder den Transaktionskontext aufzuteilen \citep[172]{MüllerWehr2012}.
Zusätzlich kann hier ebenfalls noch der \textit{Second Level Cache} (L2-Cache) aktiviert werden.
Dieser Cache steht jedem Persistenzkontext zur Verfügung und kann dadurch die Anzahl der
Datenbankzugriffe deutlich reduzieren, was bei langsamen Datenbank-Anbindungen zu hohen
Performance-Gewinnen führen kann.
Engegen der Verwendung spricht, dass die Daten im Second Level Cache explizit über Änderungen
informiert werden müssen, sonst werden beim nächsten Laden wieder die alten Werte geliefert.
Ebenfalls benötigt so ein Cache einen höheren Bedarf an Arbeitsspeicher, in diesem dann die
Daten parallel zur Datenbank bereitgestellt werden.
Daher ist die Benutzung nur problemlos bei Entities, auf die meist lesend zugeriffen werden.
% Zum ende noch, warum wird das gemacht? => Weil Datenbank-Definition immer unterschiedlich sind, und die Optimierung an den entsprechenden
% Datenbestand angepasst werden muss

Binary file not shown.