Java, сессионный компонент без сохранения состояния - PullRequest
4 голосов
/ 17 января 2010

Сессионные компоненты без сохранения состояния не поддерживают состояние. Значит ли это, что они не должны иметь переменных экземпляра?

Спасибо
Roger

Ответы [ 4 ]

9 голосов
/ 17 января 2010

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

  • reserveSeatsOnFlight();
  • chooseMealPreference();
  • confirmBooking().

Имеется диалоговое состояние, означающее, что второй вызов должен быть выполнен для того же компонента, что и первый вызов, иначе это просто не будет иметь смысла. Это то, что делают сессионные компоненты с состоянием.

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

Позвольте мне привести вам пример. Представьте себе этот вызов в сеансе без состояния:

public void bookFlight(List<Passsenger> passengers, FlightNumber flight, Date date) {
  ...
}

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

Итак, возвращаясь к первому примеру, один из способов справиться с этим - передать состояние вызывающей стороне:

public interface ReservationSystem {
  public int createNewBooking();
  public int reserveSeatsOnFlight(int bookingId, int seats);
  public int chooseMealPreference(int bookingId, ...)
  ...
}

Видите, как вышеупомянутое больше не имеет разговорного состояния? Ну, это так, но теперь оно заключено в bookingId, который вы передаете. Сессионный компонент без сохранения состояния может получить бронирование и продолжить с того места, где остановился другой.

1 голос
/ 13 июня 2012

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

1 голос
/ 17 января 2010

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

Сказав это, это, по сути, глобальные переменные в вашем объекте, и они могут злоупотреблять (как это было в большинстве случаев, которые я также видел). Я бы рекомендовал избегать их.

Могут быть случаи, когда они полезны, хотя ... Вы имеете в виду конкретный вариант использования?

0 голосов
/ 06 ноября 2012

Как насчет хранения final переменных экземпляра, которые инициализируются при запуске SLSB (то есть в конструкторе).Я имею в виду атрибут DAO, который создается в конструкторе SLSB, например:

    @Stateless
    public class MyStatelessBean() {    
    private final CustomerDAO customerDAO;

        public MyStatelessBean() {
               // Initialization code goes here
               this.customerDAO = new CustomerDAO();
        }
    ...
    }

Таким образом, DAO можно использовать непосредственно в методах SLSB, и его не нужно создавать каждый раз, когдаДАО нужен.При условии, конечно, что DAO не имеет гражданства, что обычно имеет место.Соединения с базой данных, разумеется, будут предоставляться по запросу и никогда не сохраняться в самой SLSB.

...