Явное использование EntityManager с репозиториями Spring Data

Когда мне нужно явно обращаться к методам EntityManager (меня особенно интересуют функции clear(), close(), flush(), detach()) в моих методах обслуживания, которые дополнительно работать с репозиториями Spring Data?Явное использование EntityManager с репозиториями Spring Data

Меня больше всего интересует общее понимание предмета. Скажем, в одном приложении я нашел это:

for (MyEntity myEntity: entities) { 
     ...some logic here 
     mySpringDataRepo.save (myEntity); 
    } 
    entityManager.flush(); 
    entityManager.clear();

Я нашел такое использование EntityManager оправданной, так как память может быть перегружен субъектами. Однако в другом фрагменте кода:

mySpringDataRepository.save(entity); 
    entityManager.detach(entity);

Нужно явно отделить сущность? Не использует ли Spring данные самостоятельно?

Я также нашел этот пост: http://newscentral.exsees.com/item/de38b01b7a9f794a124e2c72b97d1103-c5533957a4140e3c51e7d295ec840d08

, которые путают меня еще больше.

Что касается метода close(), я считаю, что нет необходимости называть его в среде EE. Я прав?

PS: мои конфигурации очень мейнстрим: JpaTransactionManager/LocalContainerEntityManagerFactoryBean

источник

2015-04-14 yuranos87

Вам не нужно беспокоиться о менеджеров сущностей. Если вы хотите вручную сбросить вызов метода flush в репозитории или saveAndFlush, если вы сохраняете объекты один за другим. Лично я не беспокоюсь, мои вызовы метода репозитория происходят из транзакционной службы, и когда этот метод выполняет коммит, он заканчивает выполнение флеша.

Кстати, вам не нужно проходить через коллекцию, чтобы сохранить каждую сущность. Просто сохраните сборку.

источник

2015-04-14 08:21:15 PaulNUK

Просто небольшая поправка: Хранилища должны расширить JpaRepository для доступа к методам flush и saveAndFlush. CrudRepository не содержит этих методов. – dunni

@Paul, я знаю о возможности сохранить всю коллекцию сразу, но в этом конкретном случае это было сделано по какой-то причине. Смотрите, где я поставил «... какая-то логика здесь», на самом деле довольно несколько строк кода, которые должны обрабатываться в обход. – yuranos87

@PaulNUK: Что делать, если мы используем несколько разных репозиториев в рамках одной транзакции/одного пользовательского запроса/одного транзакционного метода? Будут ли все они использовать один экземпляр EntityManager или новый для каждого репо? – yuranos87

Я бы сказал, что клиенты-репозитории должны никогда, никогда взаимодействовать с API нижнего уровня, чем сам репозиторий. Взаимодействие с API доступа к данным - это то, что репозиторий должен абстрагироваться.

Если вы думаете об этом, то возникает много проблем:

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

Таким образом, ответ довольно прост: определите, каков ваш фактический прецедент. Если стандартные механизмы Spring Data (методы запроса, выполнение предикатов) не позволяют моделировать это из коробки, добавьте пользовательскую реализацию, например. описанный here и реализовать эту функциональность внутри репозиторий. И нет, em.detach() is не прецедент.

источник

2015-04-15 07:02:33

Явное использование EntityManager с репозиториями Spring Data

ответ

Смежные вопросы