Какова область транзакции в типичном EJB3 / JPA / JSF? - PullRequest
Новая
       18

Какова область транзакции в типичном EJB3 / JPA / JSF?

4 голосов
/ 23 декабря 2011

Предположим, у вас есть веб-приложение со стеком EJB3 / JPA и JSF. AFAIK Вы можете создавать свои экраны, используя различные управляемые bean-компоненты, например, предположим, что HeaderBean и ListingBean. Поскольку в EJB3 AFAIK нет шаблона OSIF, сколько различных транзакций выполняется в следующем псевдокоде: 

@ManagedBean
class HeaderBean {
  @PreConstruct
  load(){
    // enters transaction boundary, probably will create a new tx
    headerInfo = ejb.loadFromDb();
  }
}

@ManagedBean
class ListingBean{
  @PreConstruct()
  list(){
    // enters transaction boundary, probably will NOT join the headerBean tx
    List<Data> listing = eao.loadFromDb(0, 20);
  }
}

AFAIK при выходе из слоя EJB все транзакции фиксируются; поэтому, если я вызову две разные SLSB из уровня представления, он будет выполняться в двух разных транзакциях (и, возможно, нарушит мои ACID ожидания, верно?).

Разъяснение : Мне известно о транзакционном поведении EJB3, таком как required, never, requires_new и так далее. Мой вопрос больше о том, как View-First (такой как JSF) продвигает этот вид дизайна, где данные экрана могут потенциально охватывать несколько транзакций, и, следовательно, потенциально неточны.

Я предпочитаю более длинные транзакции, но правильные данные, чем короткие транзакции, но неверные данные. Мне было интересно, способствуют ли это каким-либо новым фреймворкам, таким как jBoss Seam, или предлагают альтернативный дизайн (например, шаблон Open-Session-In-View).

1 Ответ

2 голосов
/ 23 декабря 2011

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

В вашем коде при входе в EJB транзакция не выполняется, поэтому, как вы говорите, при возврате из EJB любая транзакция была разрешена.

Хотя это кажется потенциально проблематичным, поскольку выпотенциально получить противоречивые представления данных, я думаю, что это поведение желательно.Мы хотим, чтобы время, затрачиваемое на транзакцию, было коротким - в противном случае блокировки базы данных удерживаются в течение длительных периодов и, следовательно, страдает параллелизм.

Уровень EJB следует рассматривать как обеспечивающий атомарные сервисы, который разработан и используется соответствующим образом.Я не знаю, правильно ли я читаю ваш код, но использование отдельных методов доступа для заголовка и тела может быть не лучшим вариантом.Если вам нужна согласованность между заголовком и извлечением из тела, все данные в одном вызове могут быть предпочтительны, и на самом деле более эффективно это делается в одном взаимодействии с БД.

- добавлено --- Вы уточнили в своем вопросе, что выдействительно обеспокоены согласованностью между различными частями экрана, которая в случае кодирования с использованием простых методов JSF будет использовать отдельные транзакции.

По моему мнению, подход JSF по умолчанию является приемлемым, когда такие несоответствия либо маловероятны, либо неизбежны.Примеры: 1).Маловероятно: запрашивать исторические данные, общее количество вчерашних транзакций и список вчерашних транзакций.В системе, где история не может изменить, такие отдельные запросы будут согласованы.2).Неизбежно: сводные данные поступают из одной системы, подробности из другой системы, между этими двумя системами нет координации транзакций, мы не можем обеспечить согласованность.Мы просто должны предоставить пользователю указания на то, что эти два представления могут быть немного несогласованными.

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

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

...