EJB Persistenz mit Java SE (3. Teil)

Hier wird also eine neue Version erzeugt, deren Name festgelegt und ihr Parent auf currentApplication festgelegt. Schließlich wird die Version zur Versionsliste von currentApplication hinzugefügt. Zum Abschluss der Datenbanktransaktion muss jetzt nur noch ein Update/Merge von currentApplication ausgeführt werden. Ein Problem gibt es jedoch mit diesem Code: Die neu erzeugte Version ist jetzt nicht in der Liste ausgewählt. Wenn der EntityManager die Kaskadierung übernommen hat, wird die neue Instanz der Version nicht verwaltet, im Gegensatz zum Speichern von Application über addApplication(), wo das Objekt ausdrücklich verwaltet wird. Der Code wird an dieser Stelle nicht funktionieren, denn wenn man versucht, die Version am Ende der Liste auszuwählen, ist die Shell von Version nicht vorhanden, nur eine andere verwaltete Instanz von Version, die darauf basiert. Die Lösung ist einfach, man muss nur die verwaltete Version auslesen. Dies wird von der Methode getVersion übernommen:

Die Methode getSingleResult für eine Abfrage gibt nur ein Ergebnis zurück oder eine Exception, wenn kein Ergebnis oder mehrere Ergebnisse gefunden werden. In diesem Fall wird Null als Rückgabewert festgelegt. Nun kann die Methode addVersion entsprechend geändert werden und zusätzlich kann damit geprüft werden, dass keine Duplikate erzeugt werden. In diesem Fall wird eine Exception verursacht:

Nun ist die neu erzeugte Version automatisch ausgewählt. Als Übung für den Leser enthält der Code zum Erzeugen einer Lizenz einen ähnlichen Fehler, der entsprechend behoben werden kann.

Wenn man mit einem erweiterten Persistenz-Kontext arbeitet, muss man beachten, dass persistierende Entities synchron gehalten werden müssen. Es gibt zwei Ansätze, dies zu tun. Wenn beispielsweise ein Anwender einer Lizenz zugeordnet wird, muss dabei die Lizenzsammlung des Anwenders aktualisiert werden und der Anwender muss der Anwendersammlung zur Lizenz hinzugefügt werden. In der Methode addUsersToLicense im Controller wird sichergestellt, dass beides berücksichtigt wird:

Es mag natürlich nicht zweckmäßig sein, dies so zu tun. Der andere Ansatz schickt eine Anfrage zur Aktualisierung eines verwalteten Objekts an den EntityManager, um es so mit der Datenbank zu synchronisieren. Das erreicht man mit einer Refresh-Methode in der Klasse LicManStore:

So werden nur die Instanzen von User aus der Datenbank aktualisiert:

Mit einem Standard-Transaktionskontext für den EntityManager würde dieser typischerweise neu erzeugt und es gäbe keine fortbestehenden verwalteten Objekte, die nicht aus der Datenbank aktualisiert wurden.

Schließlich ein Blick auf den „Lizenzbericht“, der alle Lizenzen zu einem Anwender auflistet. Er wird angezeigt, wenn man auf einen Anwender in der Anwenderliste doppelklickt. Hier werden nur die Beziehungen durchlaufen, um die Namen der Anwendung und der Version aus der Anwendungsliste der Klasse User zu erhalten:

Hier erfolgt also kein Datenbankzugriff, da der EntityManager die Zusammenstellung der entsprechenden Klassen License, Version und Application übernimmt, was über den erweiterten Persistenzkontext möglich ist. Dafür muss man jedoch einen Preis zahlen, insbesondere in Bezug auf den Speicherbedarf während der Laufzeit der Anwendung, die die Objekte im Cache behält. Daher sollte man in der Planung von JPA immer den Transaktionskontext in Betracht ziehen und bei Bedarf einen EntityManager erzeugen.

Damit sind unsere Betrachtungen zur Anwendung von JPA in der Java Standard Edition abgeschlossen. JPA mit ihren Wurzeln in der Java Enerprise Edition ist nicht nur für Java SE geeignet. Die hier verwendeten Entity-Klassen können auch in Enterprise-Applikationen ohne Änderungen verwendet werden. Der eigentliche Unterschied besteht darin, wie man einen EntityManager erhält und wie dieser konfiguriert wird. Diese Portabilität ist eine herausragende Eigenschaft von JPA. Was man sich in Java SE aneignet, kann auch in Java EE angewendet werden.