Изучаем Java EE 7 - [118]

Листинг 7.8. Сессионный EJB-компонент с сохранением состояния ShoppingCartEJB

@Stateful
@StatefulTimeout(value = 20, unit = TimeUnit.SECONDS)
public class ShoppingCartEJB {
··private List cartItems = new ArrayList<>();
··public void addItem(Item item) {
····if (!cartItems.contains(item))
······cartItems.add(item);
··}
··public void removeItem(Item item) {
····if (cartItems.contains(item))
······cartItems.remove(item);
··}
··public Integer getNumberOfItems() {
····if (cartItems == null || cartItems.isEmpty())
······return 0;
····return cartItems.size();
··}
··public Float getTotal() {
····if (cartItems == null || cartItems.isEmpty())
······return 0f;
····Float total = 0f;
····for (Item cartItem: cartItems) {
······total += (cartItem.getPrice());
····}
····return total;
··}
··public void empty() {
····cartItems.clear();
··}
··@Remove
··public void checkout() {
····// Выполнить некоторую бизнес-логику
····cartItems.clear();
··}
}

Рассмотренная нами ситуация с корзиной — это стандартный подход к использованию EJB-компонентов с сохранением состояния, при котором контейнер автоматически обеспечивает поддержание диалогового состояния. Единственная необходимая аннотация — @javax.ejb.Stateful, которая обладает тем же API-интерфейсом, что и аннотация @Stateless, описанная в листинге 7.7.

Обратите внимание на опциональные аннотации @javax.ejb.StatefulTimeout и @javax.ejb.Remove. Аннотацией @Remove снабжен метод checkout(). Это приводит к тому, что экземпляр EJB-компонента навсегда удаляется из памяти после вызова метода checkout(). Аннотация @StatefulTimeout присваивает значение времени ожидания, в течение которого EJB-компоненту разрешено оставаться незадействованным (не принимающим никаких клиентских вызовов), прежде чем он будет удален контейнером. Единицей времени в случае с этой аннотацией является java.util.concurrent.TimeUnit, поэтому значение может быть начиная с DAYS, HOURS… до MILLISECONDS (по умолчанию — MINUTES). В качестве альтернативы вы можете обойтись без этих аннотаций и положиться на контейнер, который автоматически удалит экземпляр, когда сессия клиента завершится или ее время истечет. Однако обеспечение удаления экземпляра в соответствующий момент способно уменьшить потребление памяти. Это может быть критически важным для приложений с высокой степенью конкуренции.

Одиночные EJB-компоненты

Одиночный EJB-компонент — это сессионный EJB-компонент, экземпляр которого создается по одному на приложение. Он реализует широко используемый шаблон Singleton («Одиночка») из знаменитой книги «Банды четырех» под названием «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object-Oriented Software), авторами которой выступили Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон М. Влиссидес (Addison-Wesley, 1995). Использование одиночного EJB-компонента гарантирует, что во всем приложении будет только один экземпляр класса, и обеспечивает глобальную точку для доступа к нему. Бывает много ситуаций, в которых требуются одиночные объекты, то есть когда вашему приложению нужен только один экземпляр объекта: это может быть мышь, оконный менеджер, спулер принтера, файловая система и т. д.

Другой распространенный сценарий применения — система кэширования, при которой все приложение совместно использует один кэш (например, Hashmap) для размещения объектов. В среде, управляемой приложением, вам потребуется немного изменить свой код, чтобы превратить класс в одиночный EJB-компонент, как показано в листинге 7.9. Прежде всего вам понадобится предотвратить создание нового экземпляра с помощью закрытого конструктора. Открытый статический метод getInstance() возвращает один экземпляр класса CacheSingleton. Если клиентскому классу понадобится добавить объект в кэш при использовании одиночного EJB-компонента, то ему потребуется вызвать:

CacheSingleton.getInstance(). addToCache(myObject);

Если вы хотите, чтобы ваш код был потокобезопасным, то вам придется воспользоваться ключевым словом synchronized для предотвращения интерференции потоков и появления несогласованных данных. Вместо Map вы также можете задействовать java.util.concurrent.ConcurrentMap, что приведет к намного более конкурентному и масштабируемому поведению. Такой подход может оказаться полезным, если эти особенности будут критически важными.

Листинг 7.9. Java-класс, следующий шаблону проектирования Singleton («Одиночка»)

public class Cache {
··private static Cache instance = new Cache();
··private Map cache = new HashMap<>();
··private Cache() {}
··public static synchronized Cache getInstance() {
····return instance;
··}
··public void addToCache(Long id, Object object) {
····if (!cache.containsKey(id))
······cache.put(id, object);
}
··public void removeFromCache(Long id) {
····if (cache.containsKey(id))
······cache.remove(id);
··}
··public Object getFromCache(Long id) {
····if (cache.containsKey(id))
······return cache.get(id);
····else
······return null;
··}
}

В EJB 3.1 был представлен одиночный сессионный EJB-компонент, который следует шаблону проектирования Singleton («Одиночка»). После создания экземпляра контейнер убеждается в том, что в течение времени выполнения приложения будет присутствовать единственный экземпляр одиночного EJB-компонента. Экземпляр совместно используется несколькими клиентами, как показано на рис. 7.6. Одиночные EJB-компоненты поддерживают свое состояние между клиентскими вызовами.