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.
Neueste Kommentare
Noch keine Kommentare zu EJB Persistenz mit Java SE (3. Teil)
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.