181 lines
13 KiB
TeX
181 lines
13 KiB
TeX
\documentclass{uebung}
|
||
|
||
\author{Linus Nagel}
|
||
\chapter{6}
|
||
|
||
\begin{document}
|
||
|
||
\maketitle
|
||
|
||
\begin{exercises}
|
||
|
||
\item \textbf{Worum handelt es sich bei einer Transaktion?}
|
||
|
||
Eine Transaktion ist eine Aneinanderreihung von Einzelaktionen, die als atomare Einheit behandelt wird. Vor der ersten Aktion wird die Transaktion eröffnet und der vorherige Zustand zwischengespeichert. Laufen alle Schritte fehlerfrei ab, werden die Änderungen dauerhaft bestätigt (\emph{commit}); bei einem Fehler wird der ursprüngliche Zustand wiederhergestellt (\emph{rollback}). Der Application Server stellt dabei das \textbf{ACID}-Prinzip sicher:
|
||
\begin{itemize}
|
||
\item \textbf{Atomicity} – Alle Teilschritte oder keiner wird ausgeführt.
|
||
\item \textbf{Consistency} – Der Datenbestand ist nach der Ausführung stets konsistent.
|
||
\item \textbf{Isolation} – Mehrere parallele Transaktionen beeinflussen sich nicht gegenseitig.
|
||
\item \textbf{Durability} – Das Ergebnis ist dauerhaft und übersteht z.\,B. einen Server-Neustart.
|
||
\end{itemize}
|
||
|
||
\item \textbf{Worin besteht der Unterschied zwischen Container Managed Transactions und Bean Managed Transactions?}
|
||
|
||
Bei \textbf{Container Managed Transactions (CMT)} übernimmt der Container die komplette Transaktionsverwaltung: Er startet die Transaktion beim Methodenaufruf, überwacht den Erfolg und leitet automatisch ein Commit oder Rollback ein. CMT ist die Voreinstellung für EJBs und wird mit \texttt{@TransactionManagement(TransactionManagementType.CONTAINER)} konfiguriert.
|
||
|
||
Bei \textbf{Bean Managed Transactions (BMT)} steuert der Entwickler die Transaktionen selbst über die JTA-Schnittstelle \texttt{UserTransaction}. Er bestimmt explizit, wann eine Transaktion beginnt (\texttt{begin()}), erfolgreich abgeschlossen (\texttt{commit()}) oder zurückgerollt (\texttt{rollback()}) wird. BMT wird mit \texttt{@TransactionManagement(TransactionManagementType.BEAN)} aktiviert.
|
||
|
||
\item \textbf{Beschreiben Sie den generellen Ablauf einer Transaktion im Application Server bei vom Container verwalteten Transaktionen.}
|
||
|
||
\begin{enumerate}
|
||
\item Ein Client ruft eine Methode einer CMT-Bean auf.
|
||
\item Der Container startet – sofern gemäß \texttt{@TransactionAttribute} erforderlich – eine neue Transaktion und erzeugt einen Transaktionskontext.
|
||
\item Die Methode wird ausgeführt. Ressourcen wie Datenbankverbindungen oder JMS-Verbindungen werden in den Transaktionskontext aufgenommen.
|
||
\item Der Transaktionskontext wird entlang der Aufrufkette an aufgerufene Methoden weiterpropagiert.
|
||
\item Am Ende der Methode wertet der Container das Ergebnis aus:
|
||
\begin{itemize}
|
||
\item Kein Fehler → \emph{commit}: alle Änderungen werden dauerhaft geschrieben.
|
||
\item System-Exception, \texttt{@ApplicationException(rollback=true)} oder \texttt{setRollbackOnly()} → \emph{rollback}: der Zustand vor der Transaktion wird wiederhergestellt.
|
||
\end{itemize}
|
||
\end{enumerate}
|
||
|
||
\item \textbf{Welche Gründe gibt es für einen Abbruch einer Transaktion? Gehen Sie dabei insbesondere auch auf unterschiedliche Typen von Exceptions ein.}
|
||
|
||
Ein Rollback wird in folgenden Fällen ausgelöst:
|
||
\begin{enumerate}
|
||
\item \textbf{System-Exception} – Exceptions, die von \texttt{RuntimeException} oder \texttt{java.rmi.RemoteException} abgeleitet sind (z.\,B. \texttt{NullPointerException}). Sie werden vom Server in eine Application-Exception verpackt und an den Client weitergeleitet. Nach einer System-Exception wird die Bean-Instanz zerstört. Durch die Annotation \texttt{@ApplicationException} kann ein Rollback für eine solche Exception verhindert werden.
|
||
\item \textbf{Application-Exception mit Rollback-Flag} – Checked Exceptions (von \texttt{Exception} abgeleitet, nicht von \texttt{RuntimeException}), die mit \texttt{@ApplicationException(rollback=true)} annotiert wurden. Ohne dieses Flag führt eine Application-Exception \emph{nicht} zu einem Rollback; sie wird direkt an den Client weitergegeben.
|
||
\item \textbf{Manuelles Markieren} – Der Entwickler ruft \texttt{sessionContext.setRollbackOnly()} auf. Der \texttt{SessionContext} wird per \texttt{@Resource} injiziert.
|
||
\end{enumerate}
|
||
|
||
\item \textbf{Worum handelt es sich bei Session Synchronisierung? Welche Methoden bzw. Annotationen umfasst die Session Synchronisierung?}
|
||
|
||
Die Session Synchronisierung ermöglicht es Stateful Session Beans, zu bestimmten Zeitpunkten über den Zustand einer laufenden Transaktion informiert zu werden. Eine Bean implementiert dazu das Interface \texttt{SessionSynchronization} oder versieht entsprechend benannte Methoden mit Annotationen:
|
||
|
||
\begin{itemize}
|
||
\item \texttt{afterBegin()} / \texttt{@AfterBegin} – wird nach dem Beginn der Transaktion aufgerufen; hier können Zustände für einen eventuellen Rollback gespeichert werden.
|
||
\item \texttt{beforeCompletion()} / \texttt{@BeforeCompletion} – wird in der ersten Phase des Zwei-Phasen-Commits aufgerufen.
|
||
\item \texttt{afterCompletion(boolean commit)} / \texttt{@AfterCompletion} – wird in der zweiten Phase aufgerufen. Der Parameter ist \texttt{true} bei erfolgreichem Commit und \texttt{false} bei einem Rollback. Hier werden zwischengespeicherte Zustände wiederhergestellt, falls nötig.
|
||
\end{itemize}
|
||
|
||
\item \textbf{Wie können Transaktionen von der Bean verwaltet werden?}
|
||
|
||
Die Bean-Klasse wird mit \texttt{@TransactionManagement(TransactionManagementType.BEAN)} annotiert. Innerhalb der Methoden erhält der Entwickler über \texttt{sessionContext.getUserTransaction()} eine Instanz von \texttt{UserTransaction} und steuert die Transaktion manuell:
|
||
\begin{minted}[breaklines]{java}
|
||
UserTransaction tx = sessionContext.getUserTransaction();
|
||
try {
|
||
tx.begin();
|
||
// Datenbankoperationen, JMS, etc.
|
||
tx.commit();
|
||
} catch (Exception e) {
|
||
tx.rollback();
|
||
}
|
||
\end{minted}
|
||
Zu beachten ist, dass BMT-Beans nicht an propagierten Transaktionen teilnehmen können; jeder \texttt{begin()}-Aufruf startet stets eine neue Transaktion.
|
||
|
||
\item \textbf{Wie können Transaktionen durch den Client verwaltet werden?}
|
||
|
||
Der Client holt sich ein \texttt{UserTransaction}-Objekt per JNDI-Lookup und steuert die Transaktion über dieselben Methoden wie bei BMT:
|
||
\begin{minted}[breaklines]{java}
|
||
InitialContext ctx = new InitialContext(properties);
|
||
UserTransaction tx = (UserTransaction) ctx.lookup("UserTransaction");
|
||
try {
|
||
tx.begin();
|
||
// Mehrere Server-Methodenaufrufe innerhalb einer Transaktion
|
||
tx.commit();
|
||
} catch (Exception e) {
|
||
tx.rollback();
|
||
}
|
||
\end{minted}
|
||
Dies ermöglicht es, mehrere Methodenaufrufe – auch über mehrere Server hinweg – in einer einzigen Transaktion zu bündeln. Der Jakarta EE Standard empfiehlt Serverherstellern, diese Möglichkeit bereitzustellen, schreibt sie jedoch nicht verbindlich vor.
|
||
|
||
\item \textbf{Betrachten Sie das Programm in den Projekten \texttt{Componentware\_Kapitel6\_Transaktionen\_Uebung} und \texttt{Componentware\_Kapitel6\_Transaktionen\_Uebung\_TestClient}. Wo finden Transaktionsaufrufe statt? An welcher Stelle findet ein Rollback statt und wo endet eine Transaktion mit einem commit?}
|
||
|
||
Die Bean \texttt{HelloWorld} ist eine Stateful Session Bean mit CMT. Da kein \texttt{@TransactionAttribute} angegeben ist, gilt die Voreinstellung \texttt{REQUIRED}: Der Container startet bei jedem Methodenaufruf vom Client aus eine eigene Transaktion. Es finden somit \textbf{vier Transaktionsaufrufe} statt – je einer pro Methode in \texttt{HelloClient}.
|
||
|
||
\begin{itemize}
|
||
\item \textbf{\texttt{sayHello1()}} wirft \texttt{HelloException1}, eine checked Exception ohne jede \texttt{@ApplicationException}-Annotation. Sie gilt als Application-Exception und führt standardmäßig \emph{nicht} zu einem Rollback → die Transaktion endet mit \textbf{commit}.
|
||
|
||
\item \textbf{\texttt{sayHello2()}} wirft \texttt{HelloException2}, eine checked Exception mit \texttt{@ApplicationException}, aber ohne das Attribut \texttt{rollback=true} (Standardwert ist \texttt{false}). Auch hier kein Rollback → die Transaktion endet mit \textbf{commit}.
|
||
|
||
\item \textbf{\texttt{sayHello3()}} ruft \texttt{Integer.parseInt("Einhundertdreiundzwanzig")} auf, was eine \texttt{NumberFormatException} auslöst. Diese leitet von \texttt{RuntimeException} ab und ist damit eine System-Exception → der Container führt einen \textbf{Rollback} durch. Da es sich um eine Stateful Session Bean handelt, wird die Bean-Instanz nach dieser System-Exception \textbf{zerstört}. Die Exception wird vom Container in eine \texttt{EJBException} verpackt und an den Client weitergegeben.
|
||
|
||
\item \textbf{\texttt{sayHello4()}} wird im Client nach dem Rollback auf derselben Bean-Referenz aufgerufen. Da die Stateful Session Bean durch die System-Exception in \texttt{sayHello3()} bereits zerstört wurde, schlägt dieser Aufruf mit einer Exception fehl (z.\,B. \texttt{NoSuchEJBException}); \texttt{sayHello4()} wird nie ausgeführt.
|
||
\end{itemize}
|
||
|
||
\item \textbf{Beschreiben Sie den Aufbau der Startklasse einer Spring Boot Applikation, also die Klasse, die die \texttt{main}-Methode enthält, für den einfachsten Fall.}
|
||
|
||
Die Startklasse wird mit \texttt{@SpringBootApplication} annotiert. In der \texttt{main}-Methode wird die statische Methode \texttt{SpringApplication.run()} aufgerufen, der die eigene Klasse als \texttt{Class}-Objekt sowie das \texttt{args}-Array übergeben werden:
|
||
\begin{minted}[breaklines]{java}
|
||
@SpringBootApplication
|
||
public class MeineApplication {
|
||
public static void main(String[] args) {
|
||
SpringApplication.run(MeineApplication.class, args);
|
||
}
|
||
}
|
||
\end{minted}
|
||
Die Annotation \texttt{@SpringBootApplication} fasst \texttt{@SpringBootConfiguration}, \texttt{@EnableAutoConfiguration} und \texttt{@ComponentScan} zusammen und aktiviert damit die Autokonfiguration sowie das Component Scanning im eigenen Paket und dessen Unterpaketen.
|
||
|
||
\item \textbf{Wie kann in Spring Boot eine Shell-Applikation erstellt werden?}
|
||
|
||
Es wird der Starter \texttt{spring-shell-starter} als Maven-Abhängigkeit eingetragen:
|
||
\begin{minted}[breaklines]{xml}
|
||
<dependency>
|
||
<groupId>org.springframework.shell</groupId>
|
||
<artifactId>spring-shell-starter</artifactId>
|
||
</dependency>
|
||
\end{minted}
|
||
Anschließend werden Methoden in einer \texttt{@Component}-Klasse mit \texttt{@Command} annotiert:
|
||
\begin{minted}[breaklines]{java}
|
||
@Component
|
||
public class HelloWorld {
|
||
@Command(description = "hello: Gibt Hello World aus")
|
||
public String hello() {
|
||
return "Hello World!";
|
||
}
|
||
}
|
||
\end{minted}
|
||
Nach dem Start der Anwendung (empfohlen: \texttt{./mvnw spring-boot:run}) steht ein interaktiver Prompt zur Verfügung, über den die Methoden im kebab-case-Format aufgerufen werden können (\texttt{\$> hello}).
|
||
|
||
\item \textbf{Gegeben Sie die folgende Klasse. Wie kann ein Objekt der Klasse \texttt{Hello} in ein Attribut einer anderen Klasse injiziert werden?}
|
||
|
||
Da \texttt{Hello} mit \texttt{@Component} annotiert ist, wird sie vom Spring-Container als Spring-managed Bean verwaltet. In einer anderen Klasse kann das Objekt über Konstruktor-Injection mit \texttt{@Autowired} injiziert werden:
|
||
\begin{minted}[breaklines]{java}
|
||
@Component
|
||
public class Greeter {
|
||
private final Hello hello;
|
||
|
||
@Autowired
|
||
public Greeter(Hello hello) {
|
||
this.hello = hello;
|
||
}
|
||
|
||
public void greet() {
|
||
System.out.println(hello.sayHello());
|
||
}
|
||
}
|
||
\end{minted}
|
||
Alternativ ist auch Feld-Injection mit \texttt{@Autowired private Hello hello;} möglich, jedoch ist Konstruktor-Injection vorzuziehen, da die Abhängigkeit dann \texttt{final} sein kann und die Klasse außerhalb des Spring-Kontexts einfacher testbar ist. Statt \texttt{@Autowired} kann auch das Jakarta-EE-Standard-Äquivalent \texttt{@Inject} verwendet werden.
|
||
|
||
\item \textbf{Welchen Vorteil bieten Spring Repositories gegenüber der Verwendung von JPA?}
|
||
|
||
Bei direkter JPA-Nutzung muss der Entwickler den \texttt{EntityManager} selbst injizieren und alle CRUD-Operationen (persist, find, remove, createQuery usw.) manuell implementieren. Spring Repositories (z.\,B. \texttt{CrudRepository}, \texttt{ListCrudRepository}, \texttt{JpaRepository}) generieren diese Standardmethoden automatisch auf Basis des Entitätstyps und des ID-Typs:
|
||
\begin{minted}[breaklines]{java}
|
||
public interface BuchRepository extends JpaRepository<Buch, Long> {
|
||
// save, findAll, findById, delete, ... werden automatisch bereitgestellt
|
||
}
|
||
\end{minted}
|
||
Der Entwickler muss lediglich ein Interface definieren, das das gewünschte Repository-Interface erweitert. Spring erstellt zur Laufzeit automatisch eine Implementierung. Dies reduziert Boilerplate-Code erheblich und vereinfacht den Datenbankzugriff.
|
||
|
||
\item \textbf{Erstellen Sie mit Spring Boot einen Web Service, der eine Methode bereitstellt, die zwei Zahlen als Path-Parameter in der URL \texttt{localhost:8080/math/sum/<zahl1>/<zahl2>} entgegennimmt. Die Methode soll diese beiden Zahlen addieren und die Summe als Ergebnis zurückliefern. Testen Sie den Service über einen Web Browser.}
|
||
|
||
\noindent\textbf{SpringDemoApplication.java}
|
||
\inputminted[breaklines]{java}{../../spring/src/main/java/org/example/demo/uebung6/SpringDemoApplication.java}
|
||
|
||
\noindent\textbf{MathWebService.java}
|
||
\inputminted[breaklines]{java}{../../spring/src/main/java/org/example/demo/uebung6/MathWebService.java}
|
||
|
||
\end{exercises}
|
||
|
||
\end{document}
|