Spring + OpenJPA TransactionRequiredException от метода обслуживания делегата - PullRequest
Новая
       30

Spring + OpenJPA TransactionRequiredException от метода обслуживания делегата

1 голос
/ 25 мая 2011

У нас проблемы с управлением транзакциями в Spring 3.0.5 и OpenJPA 2.0.1, и мы не можем точно определить проблему, поэтому любая помощь приветствуется.

Архитектура может быть поврежденаследующим образом:

сервис-уровень 

@Autowired
private DAOInterface daoReference;
....
public void doStuff() {
     boolean test = performCheck();
}
....
private boolean performCheck() {
     return daoReference._performDAOCheck();
}

DAO-уровень 

@PersistenceContext
private EntityManager entityManager;
.....
@Transactional
public boolean _performDAOCheck() {
     boolean result = true;
     // fetch entity manager, perform something and return boolean value
     return result;
}

Этот код выполняет следующие действия:Следует, но нам действительно не нравится существование транзакционной демаркации на уровне DAO, и мы хотели бы перенести это на уровень обслуживания выше.

Однако если мы переместим аннотацию @Transactional в метод делегата уровня обслуживания и удалим его из уровня DAO, мы получим javax.persistence.TransactionRequiredException, который указывает, что транзакция требуется, но не активна.

Вопрос - почему и как мы «активируем» транзакцию из метода делегата?Напомним, что мы пробовали различные модификаторы распространения транзакций, но, похоже, они ничего полезного не сделали (REQUIRES_NEW - единственное, что на самом деле применимо в этом контексте, но мы пытались использовать другие просто для того, чтобы быть в безопасности).

Стек приложений выглядит следующим образом:

  1. Spring 3.0.5
  2. Bitronix 2.1.1
  3. OpenJPA 2.0.1
  4. Tomcat6.0.32
  5. В качестве среды тестирования используется JUnit 4.8.2

1 Ответ

0 голосов
/ 26 мая 2011

Для дальнейшего использования - кажется, что мы решили проблему - речь идет о прокси Spring AOP, который не замечает локальных вызовов методов.

Если сервисный слой performCheck() перемещен в другой пружинный компонент, внедрен и затем вызван, прокси правильно генерирует новый транзакционный контекст, и вещь работает как шарм.

...