The following rules apply to callbacks:

…

Callbacks can invoke JNDI, JDBC, JMS, and enterprise beans, but NOT the EntityManager. (emphasis mine)

You stated, “The EntityRefresher gets injected the EntityManager from somewhere at some point in time prior to the actual insert taking place.” via the setEm method? Can you be more specific as to the “from somewhere” and “at some point in time prior to” ?

The idea is exactly what I need; I guess I need to play around with a little more to get it working.

“In general, portable applications should not invoke EntityManager or Query operations,
access other entity instances, or modify relationships in a lifecycle callback method.”
(page 58)

This means that it is not portable to use em.refresh(), em.find(), em.createQuery(), etc. operations in @PostPersist handler.

So, the example above works well in this concrete implementation, but it is not guaranteed to work everywhere… So, a better way would be to use @PrePersist and set entity fields there instead of trigger.

The JPA will not get back control before the database has completed the set of statements that were flushed or the transaction has been executed. In an Oracle database at least, row-level triggers (as well as statement level trigers by the way) will complete before the JPA regains control. That means that when the EntityListener is called (back), the full trigger effect will be there.

regards

Lucas

What if when the JPA engine called the insertEntity method the trigger was not completed? Is it guaranteed that the trigger completes in the same transaction that the insert is performed?

- Duke