Java Persistence API 2.1: Nur ein Minor Release?

Transaktional oder nicht?

Welche weiteren Neuerungen bietet JPA 2.1 neben der CDI-Integration? Die Integration mit Enterprise JavaBeans (EJB) ist zwar schon ein alter Hut, aber auch hier hat sich etwas getan. Bereits seit der ersten Version war es möglich, sich einen EntityManager in eine EJB injizieren zu lassen. Hierfür gab es zwei Arten: PersistenceContextType.TRANSACTIONAL und PersistenceContextType.EXTENDED. Ein EntityManager vom Typ TRANSACTIONAL hat dabei den Scope der aktuellen Transaktion, d. h. er ist immer dann geöffnet, wenn eine Transaktion aktiv ist. Im Umfeld von EJBs bedeutet das, dass er beim Eintritt in eine EJB-Methode geöffnet wird und bei der Beendigung der Methode wieder geschlossen, weil dann die Transaktion committet wird. Wenn dieses Verhalten nicht gewünscht ist (z. B. um außerhalb der EJB-Methode noch Entitäten lazy nachladen zu können), kann ein EntityManager vom Typ EXTENDED verwendet werden. Dieser kann in eine Stateful Session Bean injiziert werden und ist geöffnet, solange die Bean existiert. Wenn er konfiguriert ist, eine Container-managed Transaction zu verwenden, hängt er sich dann während der Ausführung einer EJB-Methode automatisch in die aktive Transaktion ein und schreibt die geänderten Entitäten beim Austritt aus der Methode (und dem dadurch ausgelösten Transaktions-Commit) automatisch in die Datenbank.

Es gibt allerdings Situationen, in denen dieses Verhalten nicht erwünscht ist. Befindet man sich auf einer Website, z. B. in einem Wizard, in dem man zu Beginn die zu bearbeitende Entität in den EntityManager lädt, kann es durchaus erwünscht sein, zwischen den einzelnen Wizard-Schritten eine EJB-Methode aufzurufen, ohne automatisch die bereits durchgeführten Änderungen an der geladenen Entität in die Datenbank zu schreiben, weil der Benutzer des Wizards immer noch die Möglichkeit hat, den Wizard abzubrechen. Hier kommt jetzt ein neues Feature von JPA 2.1 ins Spiel: der SynchronizationType. Bei der Injizierung durch den Container kann hiermit angegeben werden, ob der EntityManager SYNCHRONIZED oder UNSYNCHRONIZED ist. Ein SYNCHRONIZED EntityManager verhält sich dabei wie oben beschrieben, der UNSYNCHRONIZED EntityManager hingegen hängt sich nicht automatisch in eine laufende Transaktion ein und schreibt damit auch nicht „willkürlich“ zwischendurch die Daten in die Datenbank. Stattdessen kann bei Bedarf das Einhängen in die aktuell laufende Transaktion manuell über entityManager.joinTransaction()geschehen. Zusätzlich kann über die Methode entityManager.isJoinedWithTransaction()überprüft werden, ob ein EntityManager aktuell mit einer Transaktion verbunden ist. Das Schreiben der Daten in die Datenbank erfolgt dann, wie gewohnt, beim Commit der Transaktion.

Weitere Neuerungen im Early Draft von JPA 2.1

Die weiteren Neuerungen von JPA 2.1 beziehen sich im Wesentlichen auf die Erweiterung bestehender Features. So war es zwar zum Beispiel bisher möglich, Stored Procedures in der Datenbank über entityManager.createNativeQuery(.)aufzurufen, allerdings fehlte hier die Möglichkeit, OUT-Parameter der Stored Procedure hinterher abzufragen. Dies ist nun über das neue StoredProcedureQuery-Interface möglich, das man über entityManager.createStoredProcedureQuery(.)erhält. Auch in der Java Persistence Query Language (JPQL) und dem Criteria-API gibt es einige Erweiterungen und Ergänzungen. So ist die Möglichkeit der Definition einer Zusatzbedingung bei einem Join durch Unterstützung des Schlüsselwortes ON hinzugekommen. Hibernate-Usern ist dieses Feature eventuell bereits bekannt, einzig der Name des Schlüsselworts hat sich geändert. Bei Hibernate hieß es bisher WITH. Eine zusätzliche Erweiterung von JPQL und Criteria-API ist die Möglichkeit, innerhalb einer Anfrage Objekte zu casten. Möchte man z. B. bei einem Join über eine Collection nur die Members der Collection erhalten, die von einer bestimmten Unterklasse sind, kann das Schlüsselwort TREAT verwendet werden. Des Weiteren sind Bulk Updates und Bulk Deletes, die schon immer mit JPQL möglich waren, nun auch in das Criteria-API eingeflossen.

Was es nicht in den Early Draft geschafft hat

Nicht im Early Draft enthalten, aber aktuell heiß im Spezifikationskomitee diskutiert, ist die Standardisierung von Custom Convertern zur bidirektionalen Konvertierung zwischen Datenbankspalten und Objektattributen. Eine erste Version dieses Features wird sicherlich Einzug in den nächsten Draft halten.

Fazit

Der Early Draft der neuen JPA-2.1-Spezifikation überzeugt durch seine konsequente Weiterentwicklung. Besonders positiv fällt die schrittweise Integration mit anderen Java-EE-Standards auf. Neben CDI (everybody’s Darling) wird aber auch die Interaktion mit einer auf den ersten Blick nicht so coolen/interessanten Spezifikation (EJB) weiter vorangetrieben. Kleine Feature, wie die Erweiterung des Criteria-API runden den Early Draft ab!

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.