About Question enthuware.oce-jpad.v6.2.512 :

[gulokgulok]

One of the answers is: Entity s does not exist in the database.
and note below: It is possible that the database row corresponding to entity s is removed by some other process, while s is still being managed by the EntityManager. In this case, there won't be any exception.

However when I write code like this

Code: Select all

public void someMethod() {
   Employee emp = em.find(Employee.class, 1);
   try {
      Thread.sleep(5000);  // during this I remove row from database manually
   } catch (InterruptedException e) {
      e.printStackTrace();
}

em.remove(emp);
}

I get OptimisticLockException on remove. Unless my setup is wrong this note contains the error.

Regards
Jerzy

[admin]

The implementation is not compliant. As per JPA 2.0 specification section 3.1.1:

/**
* Remove the entity instance.
* @param entity
* @throws IllegalArgumentException if the instance is not an
* entity or is a detached entity
* @throws TransactionRequiredException if invoked on a
* container-managed entity manager of type
* PersistenceContextType.TRANSACTION and there is
* no transaction
*/
public void remove(Object entity);

HTH,
Paul.

[unvector]

Hello,

Let's suppose that another session bean with transaction-scoped container-managed entity manager creates the Student s entity while running one of its methods in JTA transaction. Then it calls UniversityBean.removeStudent(s).

Is there no conflict when trying to remove entity already managed by other entityManager (let's say, container-managed entity manager)?

I know that creating new application-managed EntityManager during active JTA transaction synchronizes it with this transaction, but does it mean that persistence context from this transaction is being shared with the new EntityManager in removeStudent() ?

[admin]

Of course there will be a conflict if you try to manipulate same entity from two different transactions. The result will depend on how you do the locking. One of them will fail while committing or changes of one of them will be lost.

Basically, a persistence Context will be shared across all beans that are participating in the same transaction. It is never shared by beans executing in two different concurrent transactions.

To get more clarity, you should go through Chapter 7 of JPA specification.

HTH,
Paul.

[unvector]

Thank you for your answer.

I assumed the same transaction for both container-managed Entity Manager and application-managed Entity Manager. I will try to formulate the question the other way:

While creating entity manager of any type during transaction it is "connected" (synchronized) with this transaction - does it true that persisted context being existed in current transaction so far is "reused" by application-managed Entity Manager (which, as I read in spec. usually operates on persistence context with extended scope)?

[admin]

As per Section 7.1 and 7.6.3 - A single persistence context may correspond to one or more JTA entity manager instances (all associated with the same entity manager factory). The persistence context is propagated across the entity manager instances as the JTA transaction is propagated.

Thus, if the transaction is same, then the persistence context will be the same for all those entity managers, irrespective of whether it is an application managed or container managed) that are participating in the same transaction.

As I said before, you will need to go through this chapter of the specification thoroughly to get complete understanding.

HTH,
Paul.

[unvector]

I read the spec. - but some questions still stay in my head.

So when we create application-managed entity manager during JTA transaction, the transaction-scoped persistence context is created? Because as we see in spec. entities are managed until transaction ends (via commit or rollback).

[admin]

Why do you think so?
Check out section 7.7. It clearly says:

When an application-managed entity manager is used, the application interacts directly with the persistence provider's entity manager factory to manage the entity manager lifecycle and to obtain and destroy persistence contexts.
All such application-managed persistence contexts are extended in scope, and can span multiple transactions.

The EntityManagerFactory.createEntityManager method and the EntityManagerclose and isOpen methods are used to manage the lifecycle of an application-managed entity manager and its associated persistence context.

The extended persistence context exists from the point at which the entity manager has been created
using EntityManagerFactory.createEntityManager until the entity manager is closed by means of EntityManager.close.

HTH,
Paul.

[unvector]

In chapter 7.7 we can read:

The EntityManager.close method closes an entity manager to release its persistence context and other resources. After calling close, the application must not invoke any further methods on the EntityManager instance except for getTransaction and isOpen, or the IllegalStateException will be thrown. If the close method is invoked when a transaction is active, the persistence context remains managed until the transaction completes.

Last sentence is suggestion for me, that although application-managed entity manager was closed, persistence context still exists until transaction ends. Transaction can end much later, and other beans with transaction-scoped entity managers can be called. So my question is: can we say that application-managed persistent context (for which entity manager ended) is connected to transaction, but is not accessible to other entity managers?

Also I tried the following code:

Code: Select all

    public void beanOperation() {
        Address address = new Address();
        em.persist(address);

        EntityManager em2 = emf.createEntityManager();
        Address addr2 = em.find(Address.class, address.getId());
    }

Assuming stateless session bean with transaction-scoped entity manager, after call to em.persist() transaction-scoped persistent context is created. Then I created app-scoped entity manager (which, by spec. is automatically connected to transaction), but trying to find anything in this entity manager results in null. So in this case persistent context is not shared

[admin]

You have a point. I was wrong in saying that if the transaction is same, then the persistence context will be the same for all those entity managers, irrespective of whether it is an application managed or container managed) that are participating in the same transaction.

It is true only for container managed persistence context. In Section 7.8.2, it says:

Exactly how the container maintains the association between persistence context and JTA transaction is not defined.
If a persistence context is already associated with a JTA transaction, the container uses that persistence
context for subsequent invocations within the scope of that transaction, according to the semantics for
persistence context propagation defined in section 7.6.3.

For application managed persistence context, in section 7.7, it says:

An extended persistence context obtained from the application-managed entity manager is a stand-alone
persistence context — it is not propagated with the transaction.

So yes, you are right in saying that an application-managed persistent context (for which entity manager ended) is connected to transaction is not accessible to other entity managers.

thanks for the feedback!
Paul.

[unvector]

Paul, thank you for your answer and for clarifying things.

I think that code used in the question is incorrect.

I tried to develop example similar to the one in the question, so I created two stateless beans:

Code: Select all

@Stateless
public class MyStateless {

    @PersistenceContext
    private EntityManager em;

    @EJB
    private MyService myService;

    public void createAndRemoveAddress() {
        Address address = new Address();
        address.setCity("Warszawa");
        em.persist(address);
        em.flush();
        myService.removeAddress(address);
    }
}

Code: Select all

@Stateless
public class MyService {

    @PersistenceUnit
    private EntityManagerFactory emf;

    @TransactionAttribute(value = TransactionAttributeType.MANDATORY)
    public void removeAddress(Address address) {
        EntityManager entityManager = emf.createEntityManager();
        entityManager.remove(address);
    }
}

As you see the semantics of MyService.removeAddress are pretty the same as in the question.

When I called MyStateless.createAndRemoveAddress() in client code I got IllegalStateEception:

Caused by: java.lang.IllegalArgumentException: Removing a detached instance model.Address#0

despite that there is no call to detach() and transaction still proceed.

My conclusion (from this experiment and from our discussion) is that application-managed entity manager has completely different persistent context from the transaction-scoped persistent context created before in JTA transaction, so even if there is an entity managed by the container-managed persistent context, it is seen as detached from the perspective of application-managed entity manager. So I think you should reformulate the example to not to use the app-managed persistent context.

There is no case when removeStudent() will correctly remove managed Student entity.

[admin]

What if another method in the same bean creates an EntityManager using emf.createEntityManager() and loads an entity, and then calls removeStudent method?

[unvector]

I added the following method to MyStateless bean:

Code: Select all

@Stateless
public class MyStateless {
    ...
    public void createAndRemoveAddressByAppManagedEM() {
        EntityManager em = emf.createEntityManager();

        Address address = new Address();
        address.setCity("Warszawa");
        em.persist(address);
        em.flush();

        myService.removeAddress(address);
    }
}

I've got the same IllegalArgumentException after calling createAndRemoveAddressByAppManagedEM():

Caused by: java.lang.IllegalArgumentException: Removing a detached instance model.Address#0

[admin]

You are right. Also noticed the following statement in Section 7.7: "An extended persistence context obtained from the application-managed entity manager is a stand-alone persistence context—it is not propagated with the transaction."

Paul.