Где именно соблюдена демаркация транзакции JTA для CMT? - PullRequest
0 голосов
/ 08 октября 2009

Я пытаюсь полностью понять разграничение JTA с CMT. Поведение, которое я испытываю, заключается в том, что только первый @TransactionAttribute метода уважается в EJB, а последующие вызовы метода того же компонента с различными аннотациями @TransactionAttribute - нет.

Пример:

@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class Foo implements IFoo {

   @EJB
   private IBar barBean;

   // inherits class transaction annotation of NOT_SUPPORTED
   public void doSomething() {
        barBean.doAction();
   }
}

@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class Bar implements IBar {

    public void doAction() {
        Entity entity = bar.find();
        entity.setName("new name");
        // fails with EJBException with TransactionRequiredException as cause
        save(entity);
    }

    public Entity find() {
        // return some persisted entity.
        return em.findById(1);
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public Entity save(entity) {
        em.persist(em.merge(entity));
        em.flush();
    }
}

Поведение, которое я вижу, состоит в том, что Bar.save () генерирует исключение TransactionRequiredException. Таким образом, это говорит мне, что ОБЯЗАТЕЛЬНАЯ аннотация, установленная для save (), не создает транзакцию. REQUIRES_NEW также не работает. Если я переместу save () в другой EJB, он будет работать как положено.

Означает ли это, что только первая аннотация TransactionAttribute соблюдается независимо от последующих вызовов метода для одного и того же с другими значениями аннотации? Это ошибка или ожидаемое поведение? Я не могу найти какую-либо документацию, которая конкретно объясняет это. Я ценю любое понимание этого вопроса.

Мой стек: EJB 3.0, Toplink Essentials, GF V2UR2

1 Ответ

2 голосов
/ 08 октября 2009

Мое чтение спецификации EJB 3 заключается в том, что спецификация транзакции для отдельного метода переопределяет спецификацию EJB в целом. Следовательно, ваши ожидания, которые ТРЕБУЕТСЯ, должны оправдать, но ...

это только если вы используете метод EJB в качестве компонента EJB. Когда вы делаете прямой вызов из одного бизнес-метода doAction () в другой, save (), вы не используете ссылку EJB, и, следовательно, это просто старая Java - контейнер не задействован, поэтому у контейнера нет возможности вмешиваться .

Если вы примените обязательную опцию к методу doAction (), я ожидаю, что это сработает.

Эта теория согласуется с вашими выводами о влиянии рефакторинга на другой EJB.

...