JavaEE изменяет время выполнения схемы БД для приложения SaaS - PullRequest
Новая
       30

JavaEE изменяет время выполнения схемы БД для приложения SaaS

0 голосов
/ 10 февраля 2012

Я занимаюсь разработкой приложения SaaS с использованием JavaEE технологий ( JPA, EJB, .. )

для мультитенюса, я выбрал подход «Общая база данных, отдельные схемы» и спроектировал БД ( PostgreSQL ) таким образом

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

моя бизнес-логика реализована с помощью EJB (Управляемый контейнером) , а сервер приложений - glassfishv3 поэтому в моих EJB я просто добавляю EntityManager вот так 

@PersistenceContext(unitName="DBNAME")
private EntityManager em;

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

я пытался написать @ PostConstruct обратные вызовы для EJB без сохранения состояния, внедряющих DataSource но getClientInfo () как-то возвращает null, поэтому я даже не вижу схему по умолчанию. Причина, по которой я ввел DataSource, заключалась в том, что я подумал, что нужно сделать некоторые вещи низкого уровня, чтобы указать схему.

я знаю, что если я управляю транзакциями в приложении, а не оставляю их на сервере приложений, я могу легко изменять значения EntityManager через EMF, но я хочу сохранить инфраструктуру, управляемую контейнером, и просто изменить некоторые значения во время выполнения

Есть ли способ сделать это с SessionContext или что-нибудь еще?

как лучше всего решить эту проблему?

заранее спасибо

1 Ответ

1 голос
/ 10 февраля 2012

@PostConstruct по определению неправильный путь, потому что это только намек на bean-компонент, который был сконструирован, и его зависимости были введены.Теперь компонент находится в пуле EJB, ожидающих первого вызова службы. Затем будет подключено к информации клиента этого вызова.После этого вызова информация о клиенте снова отключается.

Я думаю, что любой тип стандартного внедрения и стандартного контейнера, управляемого персистентностью, не будет работать в вашем случае, потому что внедрение выполняется ровно один раз (во время создания EJB), но ваше делопотребует внедрения для каждого вызова / транзакции службы _AND ваше внедрение будет зависеть от входных данных - клиентский запрос, содержащий идентификатор клиента.

Также: надеюсь, у вас есть только до 6 (или около того) арендаторов из-за бремени обслуживания и производительности такого подхода.Я никогда не видел такой подход , работающий в дикой природе.

...