, но нигде в JPA api он не упоминается.
На него ссылается декларативный API - свойство type
аннотации @PersistenceContext
. Было бы бессмысленно ссылаться на него через какой-либо программный c API, потому что EntityManagers
, управляемые приложением, всегда типа EXTENDED
, а тип TRANSACTION
не имеет смысл.
Управляется ли контекст сохранения (будь то транзакция или расширенный) контейнером (например, JEE), а не самим JPA?
Не совсем уверен, что понимаю вопрос, но, поскольку per spe c (Раздел 7.6):
Когда используется диспетчер сущностей, управляемый контейнером, жизненный цикл контекста постоянства всегда управляется автоматически, прозрачно для
Обратите внимание, что контекст постоянства, управляемый контейнером, EXTENDED
может быть запрошен (с использованием @PersistenceContext(type = EXTENDED)
) только в bean-компонентах с отслеживанием состояния, которые являются в настоящее время почти не используется.
(см. Этот раздел и последующие разделы для получения дополнительных сведений о том, как работают транзакции и расширенные области действия)
РЕДАКТИРОВАТЬ:
Что касается почему @PersistenceContext
и PersistenceContextType
является частью JPA API , ответ: почему бы и нет? JPA API - это в первую очередь JEE API и все, что связано с персистентностью, которое ваше приложение может захотеть использовать в качестве API. В контексте JEE - Hibernate, EclipseLink и c. являются технически не реализациями JPA API; скорее, они поставщики услуг PersistenceProvider
услуги . Это очень тонкая разница; однако, хотя они, очевидно, выполняют 99% процентов работы, с точки зрения приложения, контейнер предоставляет (предоставляет) JPA API.
(Другая точка зрения может заключаться в том, что провайдеры JPA реализуют programmati c часть API, в то время как контейнеры реализуют декларативную часть , но это чисто академический c обсуждение).