У нас есть приложение, которое имеет ряд классов сущностей, для которых должны быть две таблицы. Таблицы идентичны, с той лишь разницей, что это имя. Обычные решения, предлагаемые здесь в SO, - это использовать наследование (сопоставленный суперкласс и стратегию таблицы за класс) или две единицы персистентности с разными сопоставлениями. Мы используем последнее решение, и приложение построено поверх этого подхода, поэтому теперь оно считается заданным.
Существуют методы EJB, которые будут выполнять обновления в обоих контекстах сохранения и должны делать это за одну транзакцию. Оба контекста сохранения имеют один и тот же источник данных, который является подключением XA к базе данных Microsoft SQL Server (версия 2012 года). Единственное различие между контекстами заключается в том, что у одного есть XML-код для изменения имен таблиц для некоторых классов сущностей и, следовательно, работает с этими таблицами.
Один из лидеров архитектуры хотел бы, чтобы транзакции XA были устранены, поскольку они вызывают существенные накладные расходы в базе данных и, по-видимому, также делают регистрацию и анализ запросов, которые выполняются более сложными, возможно, также предотвращая некоторое подготовленное кэширование инструкций. Я не знаю всех подробностей, но для многих приложений нам удалось исключить XA. Для этого, однако, мы в настоящее время не можем из-за двух контекстов персистентности.
Есть ли какой-то способ в этой ситуации, чтобы обновления обоих контекстов происходили транзакционным образом без XA? Если да, то как? Если нет, возможно ли изменение архитектуры или конфигурации для использования одного контекста персистентности без необходимости обращения к подклассам для двух таблиц?
Мне известны следующие вопросы: Можно ли использовать в транзакции несколько единиц персистентности, не имея XA? и транзакция XA для двухфазной фиксации
Перед голосованием, чтобы закрыть это как дубликат, обратите внимание, что ситуации разные. Мы не в ситуации, доступной только для чтения, как в первом вопросе, оба контекста работают в одной базе данных, мы используем только MSSQL, и мы работаем над GlassFish, а не с Weblogic.