Применение мультитенантного шва + JPA

Question

Я работаю над существующим приложением Seam 2.2.0 + JPA (Hibernate 3.3.1), которое необходимо преобразовать в среду «одна база данных на клиента», где каждая схема базы данных одинакова.Приложение работает на Glassfish, использует IceFaces и имеет несколько страниц, которые используют Conversations.Он также использует один EJB для аутентификации.К сожалению, решение разделить клиентов на их собственные базы данных находится вне моего контроля.

В качестве подтверждения концепции я уже ознакомил приложение с несколькими базами данных, переместив управление EntityManagerFactory (s) иDataSource в приложение, используя абстракции Spring JPA, локальные транзакции ресурса и ThreadLocal для контекстной информации.Например, каждый раз, когда пользователь регистрируется в новом EntityManagerFactory, инициализируется с использованием нового источника данных, который связывается со своей базой данных, если он еще не был инициализирован.Это хорошо работает в тестовой среде с несколькими базами данных.

Мой вопрос: масштабируется ли этот подход для сотен баз данных?Я ожидаю добавить серверы приложений в балансировщик нагрузки для обработки дополнительной нагрузки, но потребуются ли дополнительные ресурсы для масштабирования кэша первого уровня Hibernate / JPA и / или управления контекстом шва (иначе говоря, потребление памяти) по сравнению с обычным масштабированием по сравнению с обычнымприложение с балансировкой нагрузки?Если это так, то можно ли это смягчить, выделив серверам с большим объемом оперативной памяти и / или большим распределенным кешем?

Любое понимание будет с благодарностью.

Answer 1

Я работал над приложением с этим подходом, и я могу отметить следующее:

• Управление Datasource и EntityManagerFactory - сложная задача. Однако, похоже, вы сделали это уже в тестовой среде. Дважды проверьте, правильно ли вы поступили с Seam Managed Entity Manager.
• Ваше приложение не будет хорошо масштабироваться на сотнях баз данных, поскольку у вас линейное увеличение потребления памяти для каждой базы данных. Фактически, для каждой базы данных у вас будет несколько экземпляров EntityManagerFactory (Hibernate SessionFactory), каждый из которых требует значительного количества Ram.
• Остерегайтесь возможных проблем, если вы настраиваете кэш второго уровня Hibernate. Поскольку все SessionFactories создаются из одной и той же модели данных, имена областей кэша могут конфликтовать. Я использовал hibernate.cache.region_prefix параметр конфигурации, чтобы сделать эти имена уникальными среди различных экземпляров, используя идентификатор базы данных в качестве префикса кэша.