спящий режим getCurrentSession в сети

Question

Я пишу веб-приложение с hibernate и jsp / servlet.Я читал о sessionFactory.getCurrentSession и sessionFactory.openSession методах.Я знаю основное различие между ними (при использовании getCurrentSession вам не нужно закрывать соединение, и когда вы фиксируете транзакцию, ваша сессия автоматически закрывается).Согласно моему пониманию, мы должны выбрать getCurrentSession и сделать это через сеанс для запроса.

Рассмотрим следующий сценарий:

1. Метод A вызывает getCurrentSession и получает текущий сеанс
   
2. В методе Aтранзакция запускается с использованием сеанса с шага 1
   
3. Метод A вызывает метод B, который также имеет getCurrentSession и запускает транзакцию
   
4. Метод B фиксирует свою транзакцию
   
5. Контроль возвращается к методу A, и он также фиксирует транзакцию
   

Теперь мои вопросы

1. сеанс, найденный на шаге 1, и шаг 3 будет одним и тем же сеансом?
   
2. Если ответ на вопрос 1 - да, то как он будет обрабатывать коммит на шаге 4?В идеале он должен сам закрывать сессию и должен выдавать исключение на шаге 5.
3. Если ответ на вопрос 1 - нет, то как вы справляетесь с таким сценарием?
   

Answer 1

Будет ли сеанс, найденный на шаге 1 и шаге 3, одним и тем же сеансом?

Они должны быть одинаковыми, это как-то является частью договора getCurrentSession(), и вы получите Session, привязанный к потоку, пока единица работы не будет завершена (т.е. транзакция была совершена или откатился). Java Persistence с Hibernate выглядит так (стр.481):

Весь код доступа к данным, который вызывает getCurrentSession() в глобальном общем доступе. SessionFactory получает доступ к тому же текущему Session - если он вызывается в та же нить. Единица работы завершается, когда Transaction совершается (или откатывается). Hibernate также сбрасывает и закрывает текущий Session и его постоянный контекст, если вы фиксируете или откатываете транзакцию. Здесь подразумевается, что вызов getCurrentSession() после фиксации или отката создает новый Session и новый контекст постоянства.

И, возможно, вы захотите прочесть, что говорит Javadoc Session#beginTransaction().

Если ответ на вопрос 1 положительный, то как он будет обрабатывать коммит на шаге 4. В идеале он должен сам закрывать сеанс и выдавать ошибку на шаге 5.

Шаг 4 не должен быть проблемой, Session будет сброшен, Transaction будет зафиксирован, а Session закрыт. Но я ожидаю, что шаг 5 провалится с TransactionException (это моя ставка). Но позвольте мне процитировать Javadoc Transaction:

Транзакция связана с сеансом и обычно создается с помощью вызова Session.beginTransaction(). Один сеанс может охватывать несколько транзакций, поскольку понятие сеанса (диалог между приложением и хранилищем данных) имеет более грубую детализацию, чем понятие транзакции. Однако подразумевается, что в любое время может быть не более одной незафиксированной транзакции, связанной с конкретным сеансом .

Как подчеркивалось выше, мы обсуждаем то, что не должно происходить (то есть проблема проектирования).

Answer 2

У меня нет ответа на ваш сценарий, потому что я бы не реализовал его таким образом, поскольку кажется, что он вызывает проблемы.Вместо этого я бы начал транзакцию в C, где C вызывает A и B, а C запускает коммит.Скелетно:

public void c(...) {
    try {
       transaction.begin();
       a();
       b();
       transaction.commit();
    catch (Exception e) {
       transaction.rollback();
    }
}

Итак, a() и b() здесь не фиксируют и не откатывают - откуда они знают, что вся бизнес-задача выполнена?Они могут выдать исключение или, возможно, вернуть логическое значение, чтобы сообщить вызывающему абоненту, что что-то не так, и требуется откат.