users@glassfish.java.net

Re: Surprising JPA (Toplink) Behaviour (glassfish v1 UR1)

From: <glassfish_at_javadesktop.org>
Date: Mon, 19 Mar 2007 12:42:49 PST

Some thought and questions to add to the discussion...

1. A Container Managed EMF can be either a) injected via a @PersistenceUnit annotation, which is guaranteed to be available only in the list of managed components specified by the spec, or b) via JNDI lookup, which is available in any place a JNDI lookup is supported (i.e. in a wider range of classes).

Note, that if you use UserTransaction with a Container Managed EMF, an EM created from such EMF might need to join the transaction if such transaction began after the EM has been created:

  EntityManager em = emf.createEntityManager();
  utx.begin();
  em.joinTransaction();
  ...
  utx.commit();
  em.close()

2. You can also use a Container Managed EM via either @PersistenceContext or the JNDI lookup. (same rules as above apply). See section 5 in the JPA spec for more information and basic examples.

3. Any Container Managed artifact (either EMF or EM) usually results in the proxy created by the container, i.e. its hashCode might not represent that actual inctance that handles the requests.

4. What kind of stale data are we talking about? Updates to a basic field or property should be visible to EM2 if EM1 has committed its transaction before the entity has been accessed in EM2 for the 1st time. Now, if EM2 has an EXTENDED persistence context, and that entity has been already loadded by EM2 in a previous transaction, its values will not get updated, unless either a) em.refresh() is called on that entit, b) em.clear() is called prior to accessing the entity again, or c) provider-specific hints used in the JPQL query.

thanks,
-marina
[Message sent by forum member 'mvatkina' (mvatkina)]

http://forums.java.net/jive/thread.jspa?messageID=208805