title: Understanding EJB3/JPA container-level transactions and isolation level
body: <p>Consider this simplified view of some code with which I'm working:</p>
  
  <pre><code>@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!
  }
  </code></pre>
  
  <p>I've set the <code>TransactionAttribute</code> annotation to <code>MANDATORY</code> at the class-level.  I understand this to mean that all methods such as <code>doSomething()</code> must be invoked within a supplied transaction.  We are using container-managed transactions in this case. </p>
  
  <p>The <code>TransactionAttribute</code> is not used at all in <code>SecondEjbType</code> or <code>ThirdEjbType</code>... neither at the class nor method level.  I understand this to mean that <code>secondEjb.doSomething()</code> and <code>thirdEjb.doSomething()</code> will both operate within the transaction supplied for <code>firstEjb.doSomething()</code>.</p>
  
  <p>However, I'm seriously missing out on <em>something</em>!  As indicated by the code comments... <code>secondEjb</code> writes data to a database, and <code>thirdEjb</code> 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.  <strong>However, for whatever reason the <code>secondEjb</code> database write isn't visible to <code>thirdEjb</code>.</strong>  </p>
  
  <p>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?</p>
  
  <hr>
  
  <h2>UPDATE - Additional information requested by johnstok below:</h2>
  
  <ul>
  <li>I am running in GlassFish</li>
  <li>I'm not sure what you mean by "non-standard flush mode", so I assume the answer is no.</li>
  <li>My persistence.xml file looks like this:</li>
  </ul>
  
  <p><code>&lt;persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;persistence-unit name="pu" transaction-type="JTA"&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;jta-data-source&gt;jdbc/datasource&lt;/jta-data-source&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;exclude-unlisted-classes&gt;false&lt;/exclude-unlisted-classes&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;properties&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;property name="toplink.cache.shared.default" value="false"/&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;/properties&gt;</code><br/>
  &nbsp;&nbsp;&nbsp;&nbsp;<code>&lt;/persistence-unit&gt;</code><br/>
  <code>&lt;/persistence&gt;</code></p>