Помощь с повторно используемым методом транзакции JPA с откатом - PullRequest
2 голосов
/ 30 июля 2009

Я выполняю ретроспективную поддержку отката транзакций для java-приложения на основе JPA и использую подход Ecmel Ercans к обработке отката (http://weblogs.java.net/blog/davidvc/archive/2007/04/jpa_and_rollbac.html) и перегибы JPA, связанные с откатами. Это выглядит примерно так:

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();
}

У меня есть два вопроса по этому поводу. Во-первых, потоку, в котором появляется это решение, уже два года - исправлена ​​ли проблема с управляемыми объектами и откатами с тех пор?

Если нет, то проблема в том, что решение немного громоздкое и затеняет то, что на самом деле делается. Я хотел бы сделать его универсальным методом, который я могу просто вызывать и включать любые действия JPA, в которые я хочу. Некоторое время я играл с ним, думая, что мой универсальный метод должен использовать экземпляр анонимного класса с методом команд, выполняемых в транзакции JPA.

Однако любое решение, которое я пробую с анонимными классами, становится почти таким же обременительным, как и первоначальная проблема. Это главным образом потому, что мне нужен доступ ко всем сущностям, с которыми я работаю, до или после вызова метода транзакции, а также внутри анонимного класса, обычно всех трех. Плюс дополнительные накладные расходы на перемещение данных в анонимный класс, который выглядит как пустая трата времени, когда он настолько «глубоко» погружается в код.

У кого-нибудь есть предложения по более чистому решению?

1 Ответ

3 голосов
/ 30 июля 2009

Я бы порекомендовал использовать класс Spring * JPADaoSupport в сочетании с @ поддержкой транзакционных аннотаций . Это дает вам очень простой способ разграничения ваших методов DAO с @Transactional таким образом, чтобы указать, как обрабатывать исключения, например, должно ли данное исключение вызвать откат. Он также не зависит от базового API персистентности и является единым для JDBC, Hibernate, JPA и т. Д.

Это очень декларативно, и поэтому ваша проблема слишком большого беспорядка, скрывающего бизнес-логику, значительно уменьшена.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...