Final Version

chapters/thesis/chapter01.tex

@@ -81,7 +81,7 @@ Bei den Performance"=Untersuchungen in \autoref{ch:performance-checking} werden
 die Umgebung selbst zu untersuchen und die dort bekannten Probleme zu ermitteln. Diese werden direkt bewertet, unter den
 Gesichtspunkten, ob eine Optimierung an dieser Stelle sinnvoll ist oder ob der Arbeitsaufwand dafür zu aufwendig ist.
 Zusätzlich werden noch die Vorbereitungen und die angepassten Konfigurationen für die nachfolgenden
-Performance"=Untersuchungen der Anwendung aufzeigt.
+Performance"=Untersuchungen der Anwendung aufgezeigt.
 
 Zuerst wird in \autoref{ch:performance-investigation-application} die Ausgangsmessung durchgeführt, hierbei werden 
 alle bekannten Caches deaktiviert und eine Messung durchgeführt.

chapters/thesis/chapter02.tex

@@ -11,11 +11,11 @@ geht durch mehrere Schichten des Server"=System bis die Antwort an den Client zu
 Es wird ab hier von einem \textit{GlassFish}"=Server die Rede sein. In der Praxis wird ein \textit{Payara}"=Server
 verwendet. Der \textit{GlassFish}"=Server ist die Referenz"=Implementierung von Oracle, welche für Entwickler 
 bereitgestellt wird und die neuesten Features unterstützt. Der \textit{Payara}"=Server ist aus dessen Quellcode entstanden
-und ist für Produktivumgebungen gedacht, da dieser mit regelmäßigen Aktualisierungen versorgt wird. In diesem und dem folgenden Kapitel
+und ist für Produktivumgebungen gedacht, da dieser mit regelmäßigen Sicherheitsupdates versorgt wird. In diesem und dem folgenden Kapitel
 wird für beide Anwendungen der Begriff \textit{GlassFish} verwendet.
 
 Angefangen bei der Anfrage die über den Webbrowser an den Server gestellt wird und vom \textit{GlassFish}"=Server
-empfangen wird. In diesem wird anhand des definierten Routing entschieden, an welchen \textit{Controller} im \textit{\ac{JSF}}
+empfangen wird. In diesem wird anhand des definierten Routings entschieden, an welchem \textit{Controller} im \textit{\ac{JSF}}
 die Anfrage weitergeleitet und verarbeitet wird. In diesem wird die Darstellung der Webseite geladen und die Anfragen 
 für den darzustellenden Datenbestand abgeschickt.
 

chapters/thesis/chapter05.tex

@@ -791,7 +791,7 @@ Knoten, dass die Menge der Datensätze enorm hoch ist und diese sich bis zum obe
 bedeutet, dass die Einschränkung des Datenbestandes erst am Ende der Abfrage durchgeführt wird und diesbezüglich die
 Dauer der Abfrage linear mit den Inhalt der \textit{document}"=Tabelle zusammenhängt. Des Weiteren wird für keine
 Tabelle ein \textit{Index Scan} verwendet, sondern immer mit einem \textit{Seq Scan} gearbeitet, da durch das Ermitteln
-des kompletten Datenbestandes der Optimizer entscheidet, ob der komplette Scan der Tabelle kostengünstiger ist als
+des kompletten Datenbestandes der Optimizer entscheidet, dass der komplette Scan der Tabelle kostengünstiger ist als
 die Verwendung eines der vorhandenen Indexe. Dies kann durch den Befehl \lstinline[language=SQL]|SET enable_seqscan = off|
 sehr einfach verifiziert werden. Damit wird die Verwendung von \textit{Seq Scan} deaktiviert und es wird anschließend ein
 \textit{Index Scan} verwendet. Wenn man nun beide Pläne vergleicht, sieht man die Erhöhung der Kosten bei der Verwendung 

chapters/thesis/chapter06.tex

@@ -7,11 +7,10 @@ Nun werden die durchgeführten Anpassungen anhand ihre Effektivität betrachtet
 diese eine Optimierung darstellen. Weiterhin werden die Nachteile der Anpassungen überprüft und und bei der Betrachtung
 der Effektivität mit beachtet.
 
-Es wurden die Konfigurationen der Caches von OpenJPA, \ac{JPA} und \ac{EJB} aktiviert und deren Auswirkung betrachtet. Bei den
+Es wurden die Konfigurationen der Caches von OpenJPA, \ac{JPA}, \ac{EJB} und Ehcache aktiviert und deren Auswirkung betrachtet. Bei den
 Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln, in welchem Umfang
 sich diese auswirken. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante
-Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die Abfragen an die 
+Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die 
-Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Danach werden die 
 \textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand 
 die Abfragen beschleunigt werden können. Abschließend werden die Abfragen in der Datenbank betrachtet und auf ihre
 Optimierungspotentiale hin untersucht.
@@ -103,8 +102,8 @@ explizit im Cache aufgenommen und angepinnt werden.
 \section{Cached Queries}
 \label{sec:evaluation:cached-queries}
 
-Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass %TODO Der Satz ist schwer zu lesen, hat sie gesagt
+Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dieser Cache bearbeitet nur Anfragen, 
-für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. In diesem Fall sind in der Tabelle
+die keine Bedingungen besitzen und daher ist es erklärbar, warum er für diese Abfrage nicht funktioniert. In diesem Fall sind in der Tabelle
 noch nicht freigegebene und ungültige Datensätze gespeichert, daher müssen diese vor dem Übertragen herausgefiltert
 werden. Aus diesem Grund werden die Anfragen in diesem Cache nicht gespeichert.
 

chapters/thesis/chapter07.tex

@@ -80,4 +80,5 @@ könnte.
 Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen
 von anderen \ac{ORM} könnten wie in \autoref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, 
 sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen 
-\ac{ORM} wäre ebenfalls in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.
+\ac{ORM} oder eine Kombination aus OpenJPA und eigenem Mapping wäre ebenfalls in Betracht zu ziehen, solange sich die 
+Komplexität der Daten"=Struktur nicht erhöht.