Does EntityManager remove() cause detachment

Question

Does calling EntityManager.remove(someEntity) -for other than transaction scoped entity manager- cause the entity to be detached? As I was reading the JSR-317 :

A detached entity results from transaction commit if a transaction-scoped container-managed entity manager is used (see section 3.3); from transaction rollback (see section 3.3.2); from detaching the entity from the persistence context; from clearing the persistence context; from closing an entity manager; or from serializing an entity or otherwise passing an entity by value—e.g., to a separate application tier, through a remote interface, etc.

It didn't mention that remove() causes the entity to be detached, though other web sites mentions it. please provide a reference to your answer.

Answer 1

According to the JPA 2.1 specification (Section 3.2.3 Removal, PDF page 82), we find an important piece of information, related to your question:

After an entity has been removed, its state (except for generated state) will be that of the entity at the point at which the remove operation was called.

So, the answer seems to be: It depends.

Yet, on page 80, we find another important bit of information.

A removed entity instance is an instance with a persistent identity, associated with a persistence context, that will be removed from the database upon transaction commit.

Thus, we can infer that it is not in a detached state as it is still "associated" until finally removed by the TX commit.

Digging deeper, you can consult the JPA lifecycle image provided in the answer by Vlad Mihalcea to "understand the JPA state transitions better". As depicted in the first image (JPA), an entity does not transit to the detached state, but ends up in a removed state.

Further details on the semantics of the remove(..) operation are found on page 81/82 of the JPA Spec document.

Hope it helps.