Are Entities, which was found by using the Criteria API and JPQL, automatically in the Persistence context of JPA?

Question

i have a question concerning JPA and the entity manager. If i use the find method of the entity manager, the data from database will be loaded and the entity is a part of the persistence context of the entity manager and can be deleted, modified or somthing else.

But what is the situation, if an entity will be loaded from database by using Criteria API from Hibernate or the JPQL from JPA or the HQL from Hibernate?

Is the entity or are the entities, which was founded by using Criteria API from Hibernate or the JPQL from JPA or the HQL from Hibernate, automatically a full part of the persistence context of the entity manager and can be deleted or modified as i used the find method of the entity manager?

What is the situation in this JPQL example:

JPQL:

select k, kto.kontostand from Kunde k
left join fetch k.wohnort  
left join fetch k.konten kto
where k. geschlecht = 'm' and kto. kontostand < 0

Are K and the complete Entity kontostand a fully part of the entity manager?

Thanks a lot ! Maik

Answer 1

There is no single answer on all the questions as these depends on:

• what type of entity manager/persistence context is used ( transaction-scoped or i*extended*)
• whether a given entity manager operation is invoked inside or outside a transaction
• wheter a given entity manager operation or query uses entity locking

Anyway I will try to answer your questions by quoting JPA 2.0 specification:

3.1.1 EntityManager Interface

The persist , merge , remove , and refresh methods must be invoked within a transaction context when an entity manager with a transaction-scoped persistence context is used. If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.

The find method (provided it is invoked without a lock or invoked with LockModeType.NONE ) and the getReference method are not required to be invoked within a transaction context. If an entity manager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an entity manager with an extended persistence context is used, they will be managed.

Note: apart from Java EE related container-managed persistence contexts (that is: transaction-scoped and extended) there is also application-managed persistence context which is extended in scope and can be used both in Java EE and SE environments. Make sure which one is used by you.

3.8.6 Query Execution

Query and TypedQuery methods other than the executeUpdate method are not required to be invoked within a transaction context, unless a lock mode other than LockModeType.NONE has been specified for the query. In particular, the getResultList and getSingleResult methods are not required to be invoked within a transaction context unless such a lock mode has been specified for the query. If an entity manager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an entity manager with an extended persistence context is used, they will be managed.

Assume you are using StatelessSession and prefetching kto with the query you should then get complete kontostand as detached (so it's not associated with any persistence context).

I hope it helps.

Answer 2

The CriteriaUpdate interface can be used to implement bulk update operations. But be careful, these operations are directly mapped to database update operations. Therefore the persistence context is not synchronized with the result and there is no optimistic locking of the involved entities . If you use optimistic locking, you need to update the version column as part of your update statement.

See more: Criteria Update/Delete – The easy way to implement bulk operations with JPA2.1