Как @TransactionTimeout обрабатывается WildFly? - PullRequest
0 голосов
/ 11 октября 2019

Мне интересно, как @TranscationTimeout обрабатывается WildFly, особенно при вызове чужого EJB-метода, аннотированного @TransactionAttribute, но не самого @TransactionTimeout.

Я искал Документация WildFly , API Docs и, конечно, гуглил, но я не могу найти никаких утверждений.

Рассмотрим следующий сценарий. У нас есть EJB без сохранения состояния A и B.

@Stateless
public class A {

  @Inject
  private B b;

  @TransactionTimeout(unit = TimeUnit.MINUTES, value = 10)
  public void t() {
    b.t();
  }
}

@Stateless
public class B {

  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
  public void t() {
  }
}

При вызове клиентом я ожидаю:

  • A :: t выполняется в транзакции с таймаутом 10 минут
  • B :: t выполняется в новой транзакции с тайм-аутом по умолчанию для контейнера (5 минут в WildFly)
  • B :: t в A :: t выполняется в своей новой транзакции с тайм-аутом по умолчанию для контейнера(5 минут в WildFly)

Что происходит:

  • B :: t в A :: t выполняется в своей новой транзакции с тайм-аутом 10 минут

Кажется, что @TransactionTimeout наследуется вложенным EJB-методам, если они каким-либо образом не аннотированы @TransactionTimeout, соответственно, контейнер по умолчанию переопределяется при их вызове. Требуется ли такое поведение? Существуют ли исключения?

Я использую WildFly 10.1.0 с Java 8.

1 Ответ

1 голос
/ 13 октября 2019

As TransactionTimeout-Annotation сообщает:

"Аннотация для указания времени ожидания транзакции для вновь запущенной транзакции при вызове бизнес-метода EJB"

Это означает, что imO:для вновь запущенной транзакции, а не для текущей запущенной транзакции. Следовательно, B: t подвержен влиянию, так как он запускает новую транзакцию, как, возможно, A: t, но только если он вызывается вне контекста транзакции. (по умолчанию @Requires может означать, что транзакция уже выполняется.)

Это будет соответствовать вашим наблюдениям.

...