Обратите внимание на опциональные аннотации @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-компоненты поддерживают свое состояние между клиентскими вызовами.

Рис. 7.6. Клиенты, осуществляющие доступ к одиночному EJB-компоненту