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

I’ve learned a ton from all the answers here, and can’t thank people enough. However, I believe that my question has muddied the waters to a point where it might be better to start over with a different question.

It doesn’t appear that jumping from one EJB to the next and back has anything to do with anything. To simplify matters, I tried working with a test case completely isolated to one EJB. I went into that secondEjb.doSomething() method, which persists an entity to the database. At the end of the method, I added an em.flush(), and tried retrieving the entity again with a JPA query.

Even though I was still in the exact same method where the entity had just been persisted, it was not visible to that subsequent query. I’ve done some additional research elsewhere, and it looks like this may simply be the normal mode of isolation for JPA in a transactional context. One a transaction is started, additional queries within that transaction don’t yet have visibility to uncommitted data.

If my summary of the linked CodeRanch discussion is accurate, then “yuck” on JPA! 🙂 Either way, I’ve refactored the code to avoid this issue altogether.