openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: Changes during a Listener
Date Thu, 21 Apr 2011 14:33:34 GMT
This is a bit of a gray area.. The spec (section 3.5) says :
• In general, the lifecycle method of a portable application should not
invoke EntityManager
or Query operations, access other entity instances, or modify relationships
within the
same persistence context.[43] A lifecycle callback method may modify the
state of the entity on which it is invoked.

[43] The semantics of such operations may be standardized in a future
release of this specification.

Your application might not be directly calling EntityManager.merge() or
.persist(), but you are adding a new relationship (if I follow your example
correctly) and the operation is cascaded.

The OpenJPA manual provides slightly different wording :


   Methods marked with this annotation will be invoked just the persistent
   values in your objects are flushed to the datastore. This is equivalent to
   the XML element tagpre-update.

   PreUpdate is the complement to PostLoad . While methods marked with
   PostLoad are most often used to initialize non-persistent values from
   persistent data, methods annotated with PreUpdate is normally used to set
   persistent fields with information cached in non-persistent data.

   Methods marked with this annotation will be invoked after changes to a given
   instance have been stored to the datastore. This is useful for clearing
   stale data cached at the application layer. This is equivalent to the XML
   element tag post-update.

In short, if this is going to work you should use the PreUpdate callback
instead of PostUpdate.  PostUpdate happens after we've written to the
database. I'm not sure why PostUpdate works with managed transactions
(Spring), but it's probably a happy coincidence.

Note that what you're trying to do is not covered by the JPA spec, and the
OpenJPA docs don't explicitly indicate that this _will_ work, but moving to
the PreUpdate callback should be the first step.

Hope this helps

On Thu, Apr 21, 2011 at 8:17 AM, Jim Talbut <> wrote:

> Hi,
> Under what circumstances can a PostUpdate listener create new entities?
> I have a set of entities with PostUpdate listeners that create additional
> records to track changes.
> In some of my tests this is working correctly (with the transaction managed
> by a Spring @Transaction on a Struts action) but in others (stripped back to
> handle the transaction manually) the main entity is created but the related
> (change tracking) entity is not.
> Both cases are using the same code for creating the change tracking entity
> is identical, and neither explicitly accesses the entity manager to persist
> it (relying on cascading).
> Thanks.
> Jim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message