Hilfe mit einer wiederverwendbaren JPA-Transaktionsmethode mit Rollback

Question

Ich bin Retro-Fit Transaktions-Rollback-Unterstützung für eine JPA-basierte Java-Anwendung, und verwende Ecmel Ercans Ansatz zur Behandlung Rollback (http://weblogs.java.net/blog/davidvc/archive/2007/04/jpa_and_rollbac.html) und JPA Knicks mit Rollbacks verbunden. Es sieht in etwa so aus:

EntityManager em = emf.createEntityManager(); 
EntityTransaction tx = null; 
try { 
tx = em.getTransaction(); 
tx.begin(); 
... 
... 
tx.commit(); 
} catch(Exception ex) { 
    if(tx != null && tx.isActive()) tx.rollback(); 
} finally { 
    em.close(); 
} 

Ich habe zwei Fragen dazu. Erstens ist der Thread, in dem diese Lösung auftaucht, zwei Jahre alt - wurde das Problem mit verwalteten Entitäten und Rollbacks seither behoben?

Wenn nicht, ist das Problem, dass die Lösung ein bisschen sperrig ist und verdunkelt, was tatsächlich getan wird. Ich möchte es zu einer generischen Methode machen, die ich einfach aufrufen und die JPA-Aktionen verbinden kann, die ich will. Ich habe mit der Idee gespielt, dass meine generische Methode eine Instanz einer anonymen Klasse mit einer Methode von Befehlen innerhalb der JPA-Transaktion ausführen soll.

Allerdings wird jede Lösung, die ich mit anonymen Klassen versuche, fast so umständlich wie das anfängliche Problem. Dies liegt hauptsächlich daran, dass ich Zugriff auf alle Entitäten haben muss, mit denen ich arbeite, entweder vor oder nach dem Aufruf der Transaktions-Methode, sowie innerhalb der anonymen Klasse, normalerweise alle drei. Hinzu kommt der zusätzliche Aufwand, Daten in eine anonyme Klasse zu verschieben, die sich wie eine Verschwendung anfühlt, wenn sie "weit unten" in den Code eingefügt wird.

Hat jemand einen Vorschlag für eine sauberere Lösung?

Answer 1

Ich würde empfehlen, Spring's JPADaoSupport Klasse, in Kombination mit seiner @Transactional annotation support. Dies gibt Ihnen eine sehr saubere Möglichkeit, Ihre DAO-Methoden mit @Transactional so abzugrenzen, dass Sie festlegen, wie mit Ausnahmen verfahren wird, z. sollte eine bestimmte Ausnahme einen Rollback auslösen? Es ist auch unabhängig von der zugrundeliegenden Persistenz-API und ist daher konsistent über JDBC, Hibernate, JPA, was auch immer.

Es ist sehr deklarativ, und so wird Ihr Problem von zu viel Unordnung, die die Geschäftslogik verdeckt, stark reduziert.