Umbauen nach Gespräch mit Herrn Hollstein

.vscode/settings.json

@@ -1,6 +1,6 @@
 {
     "cSpell.language": "de-de,en",
-     "cSpell.words": [
+    "cSpell.words": [
         "autovacuum",
         "editionswissenschaftlich",
         "EFFW",
@@ -8,13 +8,57 @@
         "freigeschalten",
         "Galster",
         "Glassfish",
+        "JPQL",
         "Konsolenanwendungen",
+        "Multifunktionalität",
         "Persistenzkontext",
         "Planerstatistiken",
         "Plantypen",
         "SFSB",
         "unterlagerte",
         "Wallstein",
+    ],
+    "cSpell.ignoreRegExpList": [],
+    "cSpell.overrides": [
+        {
+            "filename": "*.sql",
+            "languageId": "sql"
+        }
+    ],
+    "cSpell.ignoreWords": [
+        "Alwas",
+        "Backmatter",
+        "Classname",
+        "Datasource",
+        "Frontmatter",
+        "JNDI",
+        "Laravel",
+        "Latexmk",
+        "Mainmatter",
+        "Nautsch",
+        "Payara",
+        "Poolname",
+        "Postgresql",
+        "Ressources",
+        "Symfony",
+        "american",
+        "asadmin",
+        "classicthesis",
+        "downto",
+        "ferniunithesis",
+        "fmtutil",
+        "gpasswd",
+        "javax",
+        "jdbc",
+        "maxint",
+        "ngerman",
+        "pacman",
+        "payara",
+        "payra",
+        "postgresql",
+        "println",
+        "texlive",
+        "wedekind",
         "xsep"
     ],
 }

chapters/expose/chapter01.tex

@@ -77,11 +77,11 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
         \node (fitClient) [fit=(browser)] {};
         \node [left] at (fitClient.west) {Client};
     
-        \node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
+        \node (JSF) [block,below of=browser,node distance=7em] {Java Server Faces};
-        \node (EJB) [block,below of=JSP] {Enterprise Java Beans};
+        \node (EJB) [block,below of=JSF] {Enterprise Java Beans};
         \node (JPA) [block,below of=EJB] {Java Persistance API};
         \node (openJPA) [block, below of=JPA] {OpenJPA Cache};
-        \node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
+        \node (fitGlassfish) [fit=(JSF) (EJB) (JPA) (openJPA)] {};
         \node [left] at (fitGlassfish.west) {Glassfish};
     
         \node (memoryBuffers) [block, below of=openJPA] {Memory Buffers};
@@ -93,8 +93,8 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
         \node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
         \node [left] at (fitServer.west) {Server};
     
-        \draw[lineArrow] (browser)--(JSP);
+        \draw[lineArrow] (browser)--(JSF);
-        \draw[lineArrow] (JSP)--(EJB);
+        \draw[lineArrow] (JSF)--(EJB);
         \draw[lineArrow] (EJB)--(JPA);
         \draw[lineArrow] (JPA)--(openJPA);
         \draw[lineArrow] (openJPA)--(memoryBuffers);
@@ -249,7 +249,7 @@ Nun wird die EJB-Schicht überprüft und die aufgerufen Funktionen betrachtet, o
 Aufgaben übernehmen und dadurch schlecht optimiert werden können. Solche Funktionen sollten dupliziert werden und auf
 die jeweilige Aufgabe spezifisch zugeschnitten und optimiert werden.
 
-Abschließend ist die JSP-Schicht zu betrachten, welche noch logische Anpassungen für die Optimierungen zulässt,
+Abschließend ist die \ac{JSF}-Schicht zu betrachten, welche noch logische Anpassungen für die Optimierungen zulässt,
 wie das Einfügen von Paging. Damit kann die ermittelnde Datenmenge verringert werden, dies führt zu schnelleren
 Abfragen, weniger Daten die im Cache vorgehalten werden müssen, den Aufbau der Seite zu beschleunigen und damit auch
 die Datenmenge die an den Browser übermittelt wird zu reduzieren.

chapters/thesis/chapter02.tex

@@ -33,11 +33,11 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
         \node (fitClient) [fit=(browser)] {};
         \node [left] at (fitClient.west) {Client};
     
-        \node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
+        \node (JSF) [block,below of=browser,node distance=7em] {Java Server Faces};
-        \node (EJB) [block,below of=JSP] {Enterprise Java Beans};
+        \node (EJB) [block,below of=JSF] {Enterprise Java Beans};
         \node (JPA) [block,below of=EJB] {Java Persistance API};
         \node (openJPA) [block, below of=JPA] {OpenJPA Cache};
-        \node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
+        \node (fitGlassfish) [fit=(JSF) (EJB) (JPA) (openJPA)] {};
         \node [left] at (fitGlassfish.west) {Glassfish};
     
         \node (memoryBuffers) [block, below of=openJPA] {Memory Buffers};
@@ -49,8 +49,8 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
         \node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
         \node [left] at (fitServer.west) {Server};
     
-        \draw[lineArrow] (browser)--(JSP);
+        \draw[lineArrow] (browser)--(JSF);
-        \draw[lineArrow] (JSP)--(EJB);
+        \draw[lineArrow] (JSF)--(EJB);
         \draw[lineArrow] (EJB)--(JPA);
         \draw[lineArrow] (JPA)--(openJPA);
         \draw[lineArrow] (openJPA)--(memoryBuffers);
@@ -61,7 +61,7 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
     \label{fig:webrequest}
 \end{figure}
 
-\section{Glassfish - Enterprise Java Beans}
+\section{Glassfish - Enterprise Kirsten.Ritzmann@gmx.netJava Beans}
 \label{sec:basics:ejb}
 
 In den Java"=EE"=Anwendungen wird der \textit{Persistenzkontext} für die Anfragen vom \textit{Application"=Server}

chapters/thesis/chapter03.tex

@@ -8,24 +8,6 @@ freigegeben ist. Zum einen werden die aktuelle Mitarbeiter befragt, zu anderen w
 überprüft. Danach wird die Anwendung an sich untersucht und zum Schluss wird eine Neuentwicklung mit Hilfe anderer
 Frameworks diskutiert.
 
-\section{Aufbau der Umfrage}
-\label{sec:concept:poll}
-
-Die Umfrage wird per Email an die \mytodos{XX} Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
-unter \href{https://briefedition.wedekind.h-da.de} verwendet. Hierbei wird die gleiche Umfrage für Bearbeiter
-und Benutzer versendet.
-
-Die erste Frage ist zur Unterscheidung ob die Antworten von einen Bearbeiter oder von einem Benutzer kommt. Dies ist
-nur notwendig, um bei der Nachstellung zu unterscheiden welche Zugriffsrechte aktiv sind und diese zu unterschiedlichen
-Performance-Problemen führt.
-
-Die weiteren Fragen sind aufeinander aufgebaut. Hierbei wird zuerst überprüft, bei welchen Aktionen eine längere
-Wartezeit auftritt. Zusätzlich soll noch dazu angegeben werden, wie häufig dies auftritt, also ob dies regelmässig
-auftritt oder immer nur zu bestimmten Zeitpunkten. Des Weiteren wird die Information nachgefragt, ob die Probleme
-immer bei der gleichen Abfolge von Aktionen auftritt, oder die vorherigen Aktionen irrelevant sind.
-
-Die Umfrage wird im Anhang \ref{ap:opinion-poll} dargestellt.
-
 \section{Allgemeine Betrachtung des Systems}
 \label{sec:concept:viewsystem}
 
@@ -59,9 +41,40 @@ zwischengespeichert werden kann und daher diese Daten immer wieder direkt von de
 \section{Untersuchung der Anwendung}
 \label{sec:concept:softwarestructure}
 
+Bei der Performance-Untersuchung der Anwendung, wird sich im ersten Schritt auf die Dokumentenliste beschränkt. Anhand
+dieser können die Optimierungen getestet und überprüft werden. Im Nachgang können die daraus gewonnen Kenntnisse auf
+die anderen Abfragen übertragen werden.
+
+Die Dokumentenliste zeigt direkte und indirekte Informationen zu einem Dokument an. Hierzu gehört die Kennung des
+Dokumentes, das Schreibdatum, der Autor, der Adressat, der Schreibort und die Korrespondenzform. Nach jeder dieser
+Information kann der Bediener die Liste auf"= oder absteigend sortieren lassen. Zusätzlich wird die Liste immer nach 
+dem Schreibdatum sortiert, um die Ergebnisse bei gleichen Werten der zu sortierenden Informationen, wie dem Schreibort,
+immer in einer chronologisch aufsteigenden Form zu darzustellen.
+
+Aktuell verwenden die Editoren die Dokumentenliste um die Briefe eines Adressaten zu filtern und diese in
+chronologische Reihenfolge aufzulisten und zu untersuchen wie Kommunikation zwischen den Wedekind und dem Adressat
+abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu prüfen mit welchen Personen sich an den ...
+
+\mytodos{Hier noch mehr INfos dazu, für was genau die Editoren diese tun}
+
+Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
+notwendig. Dies wird durch die generische Abfrage in \autoref{lst:documentlist} gezeigt. Zusätzlich wird für jedes
+dargestellte Dokument eine zusätzliche Abfrage durchgeführt, die in \autoref{lst:documentlist_sub} zeigt, dass auch hier
+weitere Relationen notwendig sind.
+
+\includecode[SQL]{chapters/thesis/chapter03_documentlist.sql}{lst:documentlist}{Generische Abfrage der Dokumentenliste}
+\includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}
+
+Nach aktuellem Stand beinhaltet die Datenbank ca. 5400 Briefe, für die jeweils 2-7 eingescannte Faksimile gespeichert
+werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB Speicherplatz.
+Dadurch kommt die Datenbank aktuell auf ca. 3,8 GB.
+
+\mytodos{Die unteren Punkte nochmal untergliedern in Performance-messen und Statistiken prüfen, dann kann mit den
+Performance-messen die unterschiedlichen Aktionen durchgeführt werden in Kapitel 4}
+
 Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
-PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach in den Schichten vom
+PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach oben in den Schichten
-Glassfish"=Server.
+vom Glassfish"=Server.
 
 Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden die zuerst die Cache"=Statistik für Object"=Cache
 und Query"=Cache aktiviert \citep[315]{MüllerWehr2012}. Die somit erfassten Werte, werden über eine Webseite
@@ -88,9 +101,9 @@ emf.getCache().print();
 % \mytodos{\url{https://eclipse.dev/eclipselink/api/2.1/org/eclipse/persistence/jpa/JpaCache.html#getObject(java.lang.Class,%20java.lang.Object)}}
 
 Die Schicht \ac{EJB} besitzt keine Möglichkeit um eine sinnvolle Messung durchzuführen, daher wird hierfür keine
-weiteren Messungen eingefügt.
+direkte Messungen eingefügt.
 
-Bei den \ac{JSP} wird eine Zeitmessung eingefügt. Hierfür müssen die Seiten so erweitert werden, dass zum einen die
+Bei den \ac{JSF} wird eine Zeitmessung eingefügt. Hierfür müssen die Seiten so erweitert werden, dass zum einen die
 Zeit gemessen wird um die Daten zu ermitteln. Zum anderen wird die Zeit gemessen wie lange es dann noch dauert um die
 Seite mit den Daten zu rendern um diese an den Client auszuliefern. Diese 2 Zeiten sollen dann im Footer direkt auf der
 Seite mit dargestellt werden. Somit kann der Benutzer auch direkt sehen, wenn das laden länger gedauert hat, an welcher
@@ -100,6 +113,8 @@ Zum Schluss soll die gesamte Anwendung noch automatisiert getestet werden. Hierf
 automatisiert alle URLs der Webseite mehrfach abfragt. Die Dauer der Aufrufe der Webseiten werden gemessen und
 statistisch ausgewertet. Für einen späteren Vergleich werden diese Informationen gesichert und mit einem erneuten Aufruf
 nach den Optimierungen verglichen. Hierdurch kann auch festgestellt werden, ob die Optimierungen erfolgreich waren.
+Um die Netzwerklatenz ignorieren zu können, wird das Skript auf dem gleichen Computer aufgerufen, auf dem die Webseite
+gestartet wurde.
 Das zugehörige Script ist im Anhang \ref{ap:timing} angehängt.
 
 \section{Vergleich mit anderen Technologien}
@@ -108,13 +123,13 @@ Das zugehörige Script ist im Anhang \ref{ap:timing} angehängt.
 \mytodos{Noch tiefer eingehen?}
 
 Damit eine Umsetzung auf eine andere Technologie umgestellt werden kann, muss dies den kompletten Technologie"=Stack
-besitzen, wie dies von der \ac{JSP} unterstützt wird. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus
+besitzen, wie dies von der \ac{JSF} unterstützt wird. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus
 der Betrachtung heraus, da sie zusätzlich noch einen Backend für die Anwendungslogik (englisch business logic) benötigt.
 
 \subsection{C\# - ASP.NET Core MVC}
 \label{sec:concept:technologiecompare:aspnetcore}
 
-Beim Vergleich zu \ac{JSP} steht ASP.NET Core MVC in nichts nach. Im großen und ganzen ist der Funktionsumfang der
+Beim Vergleich zu \ac{JSF} steht ASP.NET Core MVC in nichts nach. Im großen und ganzen ist der Funktionsumfang der
 gleiche und mit dem EntityFramework gibt es ebenfalls einen sehr mächtigen \ac{ORM}. Hierbei wird die Programmierung anhand
 des \ac{MVC}"=Entwurfsmuster implementiert \citep{AspNetCore:2024:MVC}. Dieses Muster erleichtert die Trennung der
 Benutzeranforderungen, welche durch die Controller mithilfe der Modelle abgearbeitet werden, von der Bedienoberfläche,

chapters/thesis/chapter03_documentlist.sql

@@ -0,0 +1,61 @@
+SELECT DISTINCT 
+  -- document
+    t0.id, t0.createdat, t0.modifiedat, t0.validuntil, t0.envelope_id
+  , t0.firstprint_id, t0.followsdocument_id, t0.iscomplete
+  , t0.isdispatched, t0.ispublishedindb, t0.isreconstructed
+  , t0.location_id, t0.numberofpages, t0.numberofsheets
+  , t0.parentdocument_id, t0.reviewer_id, t0.signature, t0.bequest_id
+  , t0.city_id, t0.documentcategory, t0.documentcontentteibody
+  , t0.datetype, t0.enddatestatus, t0.endday, t0.endmonth, t0.endyear
+  , t0.startdatestatus, t0.startday, t0.startmonth, t0.startyear
+  , t0.documentdelivery_id, t0.documentid, t0.documentstatus
+  -- historical person
+  , t4.id, t4.createdat, t4.modifiedat, t4.validuntil, t4.firstname
+  , t4.surname, t4.title, t4.birthdatetype, t4.birthstartdatestatus
+  , t4.birthstartday, t4.birthstartmonth, t4.birthstartyear
+  , t4.birthendstatus, t4.birthendday, t4.birthendmonth, t4.birthendyear
+  , t4.deathdatetype, t4.deathstartdatestatus, t4.deathstartday
+  , t4.deathstartmonth, t4.deathstartyear, t4.deathendstatus
+  , t4.deathendday, t4.deathendmonth, t4.deathendyear, t4.dnbref
+  , t4.gender, t4.isinstitution, t4.personid, t4.pseudonym, t4.wikilink
+  -- extended biography
+  , t5.id, t5.createdat, t5.modifiedat, t5.validuntil
+  -- sitecity birth
+  , t6.id, t6.createdat, t6.modifiedat, t6.validuntil
+  , t6.extendedbiography_id, t6.city, t6.country, t6.dnbref, t6.region
+  , t6.sitecityid, t6.wikilink, t6.zipcode
+  -- sitecity death
+  , t7.id, t7.createdat, t7.modifiedat, t7.validuntil
+  , t7.extendedbiography_id, t7.city, t7.country, t7.dnbref, t7.region
+  , t7.sitecityid, t7.wikilink, t7.zipcode
+  -- sitecity
+  , t8.id, t8.createdat, t8.modifiedat, t8.validuntil
+  , t8.extendedbiography_id, t8.city, t8.country, t8.dnbref, t8.region
+  , t8.sitecityid, t8.wikilink, t8.zipcode
+  -- appuser
+  , t9.id, t9.createdat, t9.modifiedat, t9.validuntil, t9.activated
+  , t9.emailaddress, t9.firstname, t9.institution, t9.lastlogindate
+  , t9.loggedin, t9.loggedinsince, t9.loginname, t9.password
+  , t9.registrationdate, t9.salt, t9.surname, t9.title
+  -- appuserrole
+  , t10.id, t10.createdat, t10.modifiedat, t10.validuntil
+  , t10.description, t10.userrole
+FROM   public.Document t0 
+  LEFT OUTER JOIN public.DocumentCoAuthorPerson t1 ON t0.id = t1.document_id
+  LEFT OUTER JOIN public.DocumentAddresseePerson t2 ON t0.id = t2.document_id
+  LEFT OUTER JOIN public.historicalperson t3 ON t0.authorperson_id = t3.id
+  LEFT OUTER JOIN public.historicalperson t4 ON t0.authorperson_id = t4.id
+  LEFT OUTER JOIN public.sitecity t8 ON t0.city_id = t8.id
+  LEFT OUTER JOIN public.appuser t9 ON t0.editor_id = t9.id
+  LEFT OUTER JOIN public.extendedbiography t5 ON t4.extendedbiography_id = t5.id
+  LEFT OUTER JOIN public.sitecity t6 ON t4.sitecity_birth_id = t6.id
+  LEFT OUTER JOIN public.sitecity t7 ON t4.sitecity_death_id = t7.id
+  LEFT OUTER JOIN public.appuserrole t10 ON t9.appuserrole_id = t10.id
+WHERE  (t0.validuntil > NOW()
+    AND t0.ispublishedindb = true
+    AND (t1.validuntil > NOW() OR t1.id IS NULL)
+    AND (t2.validuntil > NOW() OR t2.id IS NULL)
+    AND 1 = 1
+       )
+ORDER  BY t0.startyear DESC, t0.startmonth DESC, t0.startday DESC
+LIMIT 400

chapters/thesis/chapter03_documentlist_sub.sql

@@ -0,0 +1,30 @@
+SELECT
+  -- document coauthor person
+    t0.id, t0.createdat, t0.modifiedat, t0.validuntil, t0.document_id
+  , t0.status
+  -- historical person
+  , t1.personid, t1.pseudonym, t1.wikilink, t1.id, t1.createdat
+  , t1.modifiedat, t1.validuntil, t1.comments, t1.firstname, t1.surname
+  , t1.title, t1.birthdatetype, t1.birthstartdatestatus
+  , t1.birthstartday, t1.birthstartmonth, t1.birthstartyear
+  , t1.birthendstatus, t1.birthendday, t1.birthendmonth, t1.birthendyear
+  , t1.deathdatetype, t1.deathstartdatestatus, t1.deathendstatus
+  , t1.deathstartday, t1.deathstartmonth, t1.deathstartyear
+  , t1.deathendday, t1.deathendmonth, t1.deathendyear
+  , t1.dnbref, t1.gender, t1.isinstitution
+  -- extended biography
+  , t2.id, t2.createdat, t2.modifiedat, t2.validuntil, t2.description
+  -- sitecity birth 
+  , t3.id, t3.createdat, t3.modifiedat, t3.validuntil
+  , t3.extendedbiography_id, t3.city, t3.country, t3.dnbref, t3.region
+  , t3.sitecityid, t3.wikilink, t3.zipcode
+  -- sitecity death 
+  , t4.id, t4.createdat, t4.modifiedat, t4.validuntil
+  , t4.extendedbiography_id, t4.city, t4.country, t4.dnbref, t4.region
+  , t4.sitecityid, t4.wikilink, t4.zipcode
+FROM   public.DocumentCoAuthorPerson t0
+  LEFT OUTER JOIN public.historicalperson t1 ON t0.authorperson_id = t1.id
+  LEFT OUTER JOIN public.extendedbiography t2 ON t1.extendedbiography_id = t2.id
+  LEFT OUTER JOIN public.sitecity t3 ON t1.sitecity_birth_id = t3.id
+  LEFT OUTER JOIN public.sitecity t4 ON t1.sitecity_death_id = t4.id
+WHERE  t0.document_id = ?

chapters/thesis/chapter04.tex

@@ -2,29 +2,63 @@
 \chapter{Performance-Untersuchung}
 \label{ch:performance-checking}
 
-\section{Auswertung der Umfrage}
-\label{sec:performance-checking:poll}
-
-% Auswerten ob es einen Zusammenhang zwischen bestimmten Zeiten gibt oder ob es 
-% eine bestimmte Reihenfolge gibt, bei der die Probleme auftreten
-
 \section{Auswertung des Systems}
 \label{sec:performance-checking:system}
 
-% Hier die Auswertung des Produktionsservers unterbringen
+\mytodos{Hier die Auswertung des Produktionsservers unterbringen}
-
-\section{Einbau und Aktivieren von Performance-Messung}
-\label{sec:performance-checking:performance-measure}
-
-% 
 
 \section{Statistiken im PostgreSQL auswerten}
 \label{sec:performance-checking:postgresql-statistics}
 
-% Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
+\mytodos{Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
-% prüfen, die den Cache von OpenJPE auswerten
+prüfen, die den Cache von OpenJPE auswerten}
 
 \section{Überprüfung des PostgreSQL und Servers}
 \label{sec:performance-checking:postgresql-checking}
 
-% Konfiguration vom Produktionsserver prüfen
+\mytodos{Konfiguration vom Produktionsserver prüfen}
+
+\section{Einbau und Aktivieren von Performance-Messung}
+\label{sec:performance-checking:performance-measure}
+
+\mytodos{Einbau der Messungen direkt in die Webseite bzw. in ein Log}
+
+\section{Untersuchung der Anwendung}
+\label{sec:performance-checking:investigation-application}
+
+Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance-Verbesserungen untersucht und deren
+Vor"= und Nachteile herausgearbeitet.
+
+\subsection{Caching im PostgreSQL}
+\label{sec:performance-checking:investigation-application:caching-postgresql}
+
+\subsection{Caching im OpenJPA}
+\label{sec:performance-checking:investigation-application:caching-openjpa}
+
+\subsection{Caching im \ac{JPA}}
+\label{sec:performance-checking:investigation-application:caching-jpa}
+
+\subsection{Caching in \ac{EJB}}
+\label{sec:performance-checking:investigation-application:caching-ejb}
+
+\subsection{Abfragen Native}
+\label{sec:performance-checking:investigation-application:query-native}
+
+\subsection{Abfragen JPQL}
+\label{sec:performance-checking:investigation-application:query-jpql}
+
+\subsection{Abfragen Criteria API}
+\label{sec:performance-checking:investigation-application:query-criteria-api}
+
+\subsection{materialized views}
+\label{sec:performance-checking:investigation-application:materialized-views}
+
+\subsection{cached queries}
+\label{sec:performance-checking:investigation-application:cached-query}
+
+\subsection{Umgestalten der Datenbanktabellen}
+\label{sec:performance-checking:investigation-application:new-table}
+
+\subsection{Verkleinerung der Abfragen}
+\label{sec:performance-checking:investigation-application:smaller-query}
+

chapters/thesis/chapter05.tex

@@ -1,7 +1,9 @@
 
-\chapter{Optimierung}
+\chapter{???Optimierung???}
 \label{ch:optimizing}
 
+\mytodos{Muss noch entsprechend der Auswertungen aus der Performance-Untersuchungen angeapasst werden}
+
 \section{Ermittlung der Performance-Probleme}
 \label{sec:optimizing:performance}
 

chapters/thesis/chapter06.tex

@@ -2,9 +2,9 @@
 \chapter{Evaluierung}
 \label{ch:evaluation}
 
-\mytodos{Hier noch darauf verweisen, dass eine Befragung unter den Benutzer und Entwickler nicht zielführend gewesen wäre, da zu wenige Anwender, 4 Stück}
+\mytodos{Hier noch darauf verweisen, dass eine Befragung unter den Benutzer und Entwickler nicht zielführend gewesen wäre, da zu wenige Anwender, 4 Stück,
-
+daher ist der rein technische Ansatz die einzige sinnvolle Wahl}
-\section{Befragung der Benutzer und Entwickler}
+\mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}
 
 \section{Erneute Laufzeitanalyse starten}
 

frontbackmatter/thesis/Acronyms.tex

@@ -12,7 +12,7 @@
 % Insert your acronyms here (Das Kürzel mit der längsten Bezeichnung sollte in den eckigen Klammern eingetragen werden)
 \begin{acronym}[API]
   \acro{EJB}{Enterprise Java Beans}
-  \acro{JSP}{Java Server Page}
+  \acro{JSF}{Java Server Faces}
   \acro{ORM}{Object Relational Mapping}
   \acro{MVC}{Model-View-Controller}
   \acro{HTML}{HyperText Markup Language}

marco-galster-config.tex

@@ -50,8 +50,9 @@
 %\PassOptionsToPackage{spanish,es-lcroman}{babel}
 \usepackage{babel}
 
-% Damit dies Funktioniert, muss in der "classicthesis.sty" die Zeile 153 einkommentiert werden, damit der Fehler "Black ist nicht bekannt" mehr auftritt
+% Damit dies Funktioniert, muss in der "classicthesis.sty" die Zeile 153 einkommentieren, damit der Fehler "Black ist nicht bekannt" mehr auftritt
 \usepackage{pgfplots} % External TikZ/PGF support (thanks to Andreas Nautsch)
+\pgfplotsset{compat=1.18}
 \usetikzlibrary{external,shapes.geometric, arrows, fit, arrows.meta}
 % Notwendig, damit die Fehlermeldung "Black ist nicht bekannt" gelöst ist
 % Kopiert aus "classicthesis.sty" - Zeile 153

thesis.tex

@@ -94,7 +94,7 @@
 %\renewcommand{\thechapter}{\alph{chapter}}
 \cleardoublepage
 \part{Appendix}
-\include{chapters/thesis/appendix01}
+%\include{chapters/thesis/appendix01}
 \include{chapters/thesis/appendix02}
 %\include{chapters/examples/appendix02}
 %*************************************************************************
@@ -135,7 +135,7 @@
 % 2. Bei Before Lunch "Build artifact" hinzufügen und "WedekindJSF.war" auswählen
 % 3. Unter Deployment "Artifact" "WedekindJSF.war" hinzufügen
 
-% Konfiguration Glassfisch/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden)
+% Konfiguration Glassfish/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden)
 % 1. Payara-Server starten, damit man an die Admin-Oberfläche kommt unter http://localhost:4848/
 % 2. Unter Ressources\JDBC\JDBC Connection Pools einen neuen Anlegen:
 % 2.1. Poolname vergeben