JPA Стратегии управления веб-приложениями

Question

В настоящее время мы разрабатываем веб-приложение J2EE с использованием JPA в качестве слоя доступа к данным.В настоящее время мы развиваем несколько различных стратегий использования кэширования в наших приложениях.

1. Создание EntityManager для запроса
   • Получение кэширования в пределах объема запроса, но потеря кеша приконец запроса
   • Упрощает откат любых изменений из всего запроса
2. Создание EntityManager для сеанса Http
   • Получение кэшированияв рамках сеанса
   • Ситуация усложняется с транзакциями, придется создавать новую транзакцию для каждого запроса, затем можно будет откатить изменения для запроса

Я видел обе стратегии в документации по Hibernate.Мой вопрос заключается в том, какой из них более широко используется, и если мы сделаем EntityManager за сеанс, столкнемся ли мы с проблемами синхронизации при использовании одного и того же EntityManager в разных потоках запросов?

Answer 1

Более широко используемый подход заключается в создании EntityManager для запроса. Однако это должно оставаться скрытым от вас. Вы должны использовать какой-нибудь механизм внедрения зависимостей (spring / CDI / EJB), который будет вводить правильное EntityManager, где находится @PersistenceContext.

Если вас интересует, как это достигается в общем случае, когда ваши bean-компоненты являются некими синглетонами (один bean-компонент без состояния / один пружинный bean-компонент scope singleton) - контейнер фактически внедряет прокси в целевой объект. И каждый раз, когда с прокси обращаются, он получает экземпляр current EntityManager, который (по крайней мере, в случае с пружиной) связан с ThreadLocal (= запросом в этом случае)

Обновление: Если вы хотите реализовать эту функциональность в домашней инфраструктуре, используйте прокси-сервер cglib / javassist / JDK и вставьте ее туда, где находится @PersistenceContext. Запрос = поток. Для каждого запроса, который требует доступа к данным, создайте новый EntityManager и сохраните его в ThreadLocal. Не забудьте очистить его в конце, потому что контейнеры сервлета повторно используют потоки. Из прокси вы можете получить текущее значение ThreadLocal.

Но если вы не зашли в проект, я бы предложил перейти к чему-то более стабильному, например, к spring, cdi или guice.

Answer 2

Какой сервер вы используете? Он должен иметь возможность ввести EntityManger для вас, а не требовать, чтобы приложение имело дело.