java - Understanding EJB3/JPA container-level transactions and isolation level

Question

Consider this simplified view of some code with which I'm working:

@Stateless(...)
@Remote(...)
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class FirstEjbType {

   @EJB(...)
   private SecondEjbType secondEjb;
   @EJB(...)
   private ThirdEjbType thirdEjb;

   public void doSomething() {
      secondEjb.doSomething();  // WRITES SOMETHING TO THE DATABASE
      thirdEjb.doSomething();  // CAN'T SEE THAT SOMETHING IN THE DATABASE!
}

I've set the TransactionAttribute annotation to MANDATORY at the class-level. I understand this to mean that all methods such as doSomething() must be invoked within a supplied transaction. We are using container-managed transactions in this case.

The TransactionAttribute is not used at all in SecondEjbType or ThirdEjbType... neither at the class nor method level. I understand this to mean that secondEjb.doSomething() and thirdEjb.doSomething() will both operate within the transaction supplied for firstEjb.doSomething().

However, I'm seriously missing out on something! As indicated by the code comments... secondEjb writes data to a database, and thirdEjb reads that data as part of its operation. Since all of this is running within the same transaction, I would not expect there to be any issues with isolation levels. However, for whatever reason the secondEjb database write isn't visible to thirdEjb.

I've turned tracing all the way up to the max, and there's apparently not an exception or error or rollback at issue... the initial write simply isn't visible to the subsequent read. I don't claim to be the world's greatest guru in transaction management... have I missed something obvious, or is my conceptual understanding basically correct and the issue may lie elsewhere?

---

UPDATE - Additional information requested by johnstok below:

• I am running in GlassFish
• I'm not sure what you mean by "non-standard flush mode", so I assume the answer is no.
• My persistence.xml file looks like this:

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="pu" transaction-type="JTA">
       <jta-data-source>jdbc/datasource</jta-data-source>
        <exclude-unlisted-classes>false</exclude-unlisted-classes>
        <properties>
            <property name="toplink.cache.shared.default" value="false"/>
        </properties>
    </persistence-unit>
</persistence>

Answer 1

First thing to check is that bean two and three use @PersistenceContext EntityManager to get the EntityManager and not @PersistenceUnit EntityManagerFactory followed by a createEntityManager() call.

Second, check that the DataSource is actually setup to participate in JTA transactions (autoCommit or related properties should be off).

Lastly, a quick and dirty way to check your propagation is to call the EntityManager.getDelegate() method and check the resulting object is the same throughout the expected transaction scope.

Here's how things work under the covers.... The EntityManager injected into your bean when it is created is a fake, a simple facade. When you attempt to use the EntityManager reference in a transaction, the container will actually go digging in the current transaction, find the real EntityManager that is stashed in the transaction scope and delegate your call to that EntityManager (if there is no EntityManager already in the transaction, the container will create one and add it). This real object will be the value of getDelegate(). If the value of getDelegate() is not the same (==) in secondEjb.doSomething() and in thirdEjb.doSomething() then you are not getting the expected propagation and each is talking to a different persistence context.

On a side note, beware that applying MANDATORY on the class actually only affects methods defined in that exact class, not in super classes. If you do not specify an @TransactionAttribute on a super class, those methods use the default regardless of how subclasses maybe annotated. I only mention that as it may have an impact on your understanding of your code.