Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>To be direct and to the metal, there will be no <code>javax.transaction.Synchronization</code> objects registered for the EntityManager in question until you actually <strong>use</strong> it <em>in</em> a transaction.</p> <p>We in app-server-land will create one of these objects to do the <code>flush()</code> and register it with the <code>javax.transaction.TransactionSynchronizationRegistry</code> or <code>javax.transaction.Transaction</code>. This can't be done unless there is an active transaction.</p> <p>That's the long and short of it.</p> <p>Yes, an app server could very well keep a list of resources it gave the stateful bean and auto-enroll them in every transaction that stateful bean might start or participate in. The downside of that is you completely lose the ability to decide which things go in which transactions. Maybe you have a 2 or 3 different transactions to run on different persistence units and are aggregating the work up in your Extended persistence context for a very specific transaction. It's really a design issue and the app server should leave such decisions to the app itself.</p> <p>You use it in a transaction and we'll enroll it in the transaction. That's the basic contract.</p> <p>Side note, depending on how the underlying EntityManager is handled, <em>any</em> persistent call to the EntityManager <em>may</em> be enough to cause a complete flush at the end of the transaction. Certainly, <code>flush()</code> is the most direct and clear but a <code>persist()</code> or even a <code>find()</code> might do it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload