diff --git a/chapters/thesis/chapter01.tex b/chapters/thesis/chapter01.tex
index bb0e4bf..8bd0331 100644
--- a/chapters/thesis/chapter01.tex
+++ b/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.
diff --git a/chapters/thesis/chapter02.tex b/chapters/thesis/chapter02.tex
index fa05590..e55b2bc 100644
--- a/chapters/thesis/chapter02.tex
+++ b/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.
 
diff --git a/chapters/thesis/chapter05.tex b/chapters/thesis/chapter05.tex
index d07720c..a8bc024 100644
--- a/chapters/thesis/chapter05.tex
+++ b/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 
diff --git a/chapters/thesis/chapter06.tex b/chapters/thesis/chapter06.tex
index 85d4fe5..57560c2 100644
--- a/chapters/thesis/chapter06.tex
+++ b/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 
-Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Danach werden die 
+Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt 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
-für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. In diesem Fall sind in der Tabelle
+Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dieser Cache bearbeitet nur Anfragen, 
+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.
 
diff --git a/chapters/thesis/chapter07.tex b/chapters/thesis/chapter07.tex
index 3c4a645..128ee70 100644
--- a/chapters/thesis/chapter07.tex
+++ b/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.
diff --git a/thesis.pdf b/thesis.pdf
index dfc466b..a234b07 100644
Binary files a/thesis.pdf and b/thesis.pdf differ