Aktueller Forschungsstand - JPA

chapters/expose/chapter01.tex

@@ -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