Методология построения корпоративных информационных систем на основе технологии EJB. Часть 7

Транзакции в сессионных бинах

Как не странно это звучит, сессионные бины могут участвовать в транзакциях. Есть такое понятие, как транзактивный контекст. Другими словами бизнес методы сессионного бина могут выполнятся в транзактивном контексте. Это значит, что если вы начнете транзакцию и вызовите метод какого-либо сессионного бина, то бин на котором будет вызван этот метод будет вовлечен в транзакцию и будет в текущем (вашем) транзактивном контексте. Если вы решите зафиксировать (commit) свои действия, то координатор транзакций использует ваш транзактивный контекст для этих целей что бы узнать какие бины участвовали в транзакции и сообщить им о завершении транзакции. С другой стороны сессионый бин может обратиться к сессионному контексту что бы узнать участвует он в транзакции или нет. Также во время выполнения бизнес метода, бин может решить что выполнение происходит с ошибкой и сказать транзактивному контексту что бы был произведен откат (rollback) транзакции.

Выше я описал случай когда транзакции управляются самим бином. Но есть второй режим когда транзакцией управляет сам контейнер и естественно теряется гибкость. Не буду тут пояснять второй случай что бы не запутать читателя. Второй случай будет объяснен далее.

Сущностный бин

Идея заложенная в сущностные бины следующая. Нам приходится хранить информацию в реляционных таблицах и обеспечить к ним гибкий доступ используя ООП. Есть реляционная таблица на нее нужно создать сущностный бин. Реализация сущностного бина соответствует строчки в базе данных. Сессионный бин изображен на рис. 15

Рис.15

Покажу точки соприкосновения ООП с SQL-запросами. В ejbCreate происходит INSERT, в ejbRemove - DELETE, в ejbStore - UPDATE, в ejbLoad - SELECT. На рисунке показан пример бина, который обслуживает таблицу всего с двумя столбцами PK и title. Также присутствуют поисковые методы ejbFind, которые позволяют выдергивать идентификаторы объектов из базы данных, но не отвечают за загрузку их состояний в память. Кстати, процесс перехода из строчки таблицы в объект называется материализацией, а сохранения объекта в строчку таблицы - дематериализацией. Механизм взаимодействия с сущностными бинами такой же как с сессионными, за исключением того, что на HOME-интерфейсе появляются Find-методы, которые не создают объекты в базе данных, а находят что бы с ними можно было работать. Архитектура сущностного бина отличается понятием основной ключ Primary Key, который представлен в нашем примере как класс EntityPK. Этот класс обворачивает основной ключ таблицы, которую обслуживает бин.

Источник данных DataSource

В реализации сущностного бина необходим, что бы посылать SQL-запросы использовать соединение с БД. Был придумал пул соединения с БД (DataSource). Это было сделано что бы не тратить ресурсы и время на создания новых соединений с БД. Создаются соединения через DataSource и когда бин перестает его использовать, соединения не закрывают а держат в пуле и когда другой бин просит соединение то ему отдают давно уже созданное соединение. На самом деле процесс несколько сложнее из-за транзакций, но идея изложенная выше верна.

Механизм сохранения управляемый бином

Можно самому в реализации бина прописать все взаимодействия с БД. Такой подход называется механизмом сохранения управляемый бином (Bean-Managed Persistence). Лично я считаю, что таким образом можно добиться более эффективных и гибких решений. Особенно Вы это начнете понимать когда вам в ТЗ напишут что бы бины были совместимы с 4-мя типами СУБД.

Механизм сохранения управляемый контейнером

Используя этот механизм, программист описывает в дескрипторе описания бина имя таблицы и типы ее столбцов. После этого добавляет get/set методы в реализацию бина, а механизмом синхронизации бина с БД управляет уже сам контейнер. Таким образом время разработки бина сокращается в несколько раз. Такой механизм называется Container-Managed Persistence.

TOC | Часть 8