Мое приложение интенсивно использует пул потоков, даже метод класса может быть выполнен в другом потоке, используя аспект aspectj.
Это приводит меня к вопросу о том, как спроектировать объект базы данных с использованием реализации Hibernate JPA, особенно с одним ко многим, со многими ко многим и так далее. Проблема заключается в том, что мое приложение использует шаблон сеанса для потока, который EntityManager хранится в ThreadLocal, поэтому объект, полученный в одном потоке, часто передается в другой поток. Если у меня есть одно-ко-многим подобное сопоставление в сущности, ленивое извлечение не будет работать, так как сущность устарела.
Обходной путь, который я вижу, - это вызов merge () для присоединения сущности к менеджеру сущностей потока перед любым доступом к ленивой выборочной сущности, для этого также требуется класс-оболочка для сущности, которая вызывает merge () в каждом получателе связанной сущности. Это имеет недостаток, заключающийся в том, что если я изменю некоторые поля сущности, но не захочу слиться с постоянством прямо сейчас, вызов геттера облажается.
Я провел некоторое исследование, но не нашел лучшего решения. Мне было интересно, что это должно быть обычной практикой для приложений, ориентированных на потоки. должен быть образец наилучшей практики.
другой способ - никогда не использовать такое средство «один ко многим», но это создает очень скучную нагрузку на кодирование.
У кого-нибудь есть идея получше?