title: Why does CMT commit on exit of EJB method, when transaction attribute is "Required"?
body: <p>I am consistently finding that my already-existing transaction is getting committed inside any method of an EJB marked <code>@ejb.transaction</code> <code>type="Required"</code>. Can this be correct?  </p>
  
  <p>My expectation is, an EJB "requiring" a transaction means: if there's one already there, it will politely leave it uncommitted when done so that whoever invoked begin() can continue to use it for further operations before invoking <code>commit()</code> or <code>rollback()</code>. [Of course, if there was no transaction in the first place, then the EJB method would invoke both <code>begin()</code> and <code>commit()</code>/<code>rollback()</code>.]</p>
  
  <p>Is my expectation wrong, or should I be looking for a configuration bug?</p>
  
  <p>It might be relevant to add that I'm using Hibernate 3 inside the EJB. I'm obtaining a UserTransaction before calling the EJB method. The EJB generated wrapper invokes <code>ServerTransaction.commit()</code> on exit, which Hibernate hooks into and uses the opportunity to close its Session. The error I'm getting is a Hibernate lazy loading exception, because the session is closed when I try to access getters on a Hibernate-persisted object. So technically, I'm not 100% sure whether the <code>ServerTransaction.commit()</code> I observed necessarily committed the <code>UserTransaction</code> I started (maybe <code>ServerTransaction.commit()</code> doesn't always actually follow through with a "real" commit?), but if it did not -- then on what basis is Hibernate closing the Session?</p>
  
  <p><strong>Update:</strong> <em>I believe my assumptions above were correct, but my observations were a bit off.  See below for my self-supplied Answer.</em></p>