Как координировать доступ к базам данных J2EE и Java EE?

Если вы создаете отдельно SessionFactory для старого кода и EntityManagerFactory для нового кода, это может привести к разным значениям в кеше первого уровня. Если во время одного Http-запроса вы измените значение в старом коде, но не сразу зафиксируете, значение будет изменено в кэше сеанса, но не будет доступно для нового кода, пока он не будет зафиксирован. Независимо от любой блокировки транзакции или базы данных, которая защитит постоянные значения, это сочетание двух разных сеансов Hibernate может привести к странным вещам для значений в памяти.

Я признаю, что внедренный EntityManager все еще использует Hibernate. ИМХО, самое надежное решение - получить EntityManagerFactory для PersistenceUnit и перевести его в Hibernate EntityManagerFactoryImpl. Затем вы можете напрямую получить доступ к базовому SessionFactory :

SessionFactory sessionFactory = entityManagerFactory.getSessionFactory();

Затем вы можете безопасно использовать этот SessionFactory в своем старом коде, потому что теперь он уникален в вашем приложении и используется как в старом, так и в новом коде.

Вам все равно придется решать проблему создания-закрытия сеанса и управления транзакциями. Я полагаю, что это уже реализовано в старом коде. Не зная больше, я думаю, что вам следует перенести его на JPA, потому что я почти уверен, что если EntityManager существует, sessionFactory.getCurrentSession() даст лежащий в его основе Session, но я не могу утверждать ничего об обратном.

Вы можете без проблем смешивать Hibernate Session и Entity Manager в одном приложении. EntityManagerImpl просто делегирует вызывает частный экземпляр SessionImpl .

То, что вы описываете, является аномалией конфигурации транзакции. Каждая транзакция базы данных выполняется изолированно (если вы не используете REAN_UNCOMMITED, что, я думаю, не так), но как только вы ее зафиксируете, изменения будут доступны из любой другой транзакции или соединения. Поэтому, как только транзакция зафиксирована, вы должны увидеть все изменения в любом другом сеансе Hibernate, соединении JDBC или даже в вашем инструменте управления пользовательским интерфейсом базы данных.

Вы сказали, что произошел конфликт первичного ключа. Этого не может произойти, если вы используете Hibernate Identity или генератор последовательности. Для старого генератора Hi-Lo у вас могут возникнуть проблемы, если внешнее соединение попытается вставить записи в ту же таблицу Hibernate использует старый генератор идентификаторов hi/lo.

Эта проблема также может возникнуть при наличии аномалии репликации мастер/мастер. Если у вас есть несколько узлов и нет репликации строгой согласованности, вы можете столкнуться с нарушениями ограничений первичного ключа.

Обновить

Решение 1:

При координации нового и старого кода, пытающегося вставить один и тот же объект, вы можете иметь логику выбора, чем вставки, работающую в транзакции SERIALIZABLE. Транзакция SERIALIZABLE получает соответствующие блокировки от имени тура, поэтому вы все еще можете иметь уровень изоляции READ_COMMITTED по умолчанию, в то время как только проблемные методы службы помечены как SERIALIZABLE.

Таким образом, как в старом коде, так и в новом коде эта логика запускает выборку для проверки, существует ли уже строка, удовлетворяющая ограничению выбора, только для ее вставки, если ничего не найдено. Уровень изоляции SERIALIZABLE предотвращает фантомное чтение, поэтому я думаю, что он должен предотвращать нарушения ограничений.

Решение 2:

Если вы готовы делегировать эту задачу JDBC, вы также можете изучить оператор MERGE SQL, если ваша текущая база данных поддерживает это. По сути, это операция upsert, выдающая обновление или вставку за кулисами. Эта команда намного привлекательнее, поскольку вы можете запускать ее даже при READ_COMMITTED. Единственным недостатком является то, что вы не можете использовать Hibernate для этого, и только некоторые базы данных поддерживают его.

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

Наше решение состояло в том, чтобы создать эти поисковые значения в отдельной транзакции, которая была зафиксирована немедленно; если эта транзакция прошла успешно, то мы знали, что можем использовать этот объект, а если она не удалась, то мы знали, что нам просто нужно выполнить get, чтобы получить объект, сохраненный другим процессом. Как только у нас появился объект поиска, который, как мы знали, можно было безопасно использовать в нашем сеансе, мы могли с радостью выполнить остальные модификации БД, не рискуя откатить транзакцию.

Из вашего описания трудно понять, подходит ли ваша модель данных для аналогичного подхода, когда вы, по крайней мере, сразу фиксируете начальную версию объекта, а затем, когда вы уверены, что работаете с постоянным объектом вы могли бы сделать остальные модификации БД, которые, как вы знали, вам нужно было сделать. Но если вы сможете найти способ заставить это работать, это позволит избежать необходимости совместного использования сеанса между различными фрагментами кода (и будет работать, даже если старый и новый код выполняются в разных JVM).