openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: Updates to entities via Lifecycle callback methods
Date Tue, 23 Sep 2008 09:19:37 GMT
I'm not a JPA expert, but I do totally agree : at least from a user POV
it's quite natural to use the callback method to update the entity.
Also, the OpenJPA documentation states that it is possible to do so :

"methods annotated with |PreUpdate| is normally used to set persistent
fields with information cached in non-persistent data."

It explicitly say "set persistent fields", which for a user means
calling entity.setSomething(), and also that it is normal. The only
problem I can foresee is when there are more than one EntityListener,
the first one checking the value of a field, and another one changing
that value at a later time ... but that belongs to the application logic
domain, the only support should be to make sure the user can explicitly
state the order EntityListeners are called to make sure modification
happen before checks if business logic requires that.

Also in Hibernate "pre-JPA" it was possible to update an entity from a
listener; haven't used Hibernate as a JPA ORM but I think there is no
good reason why they should have changed this.


Michael Dick wrote:
> I think there may be valid use cases where updating *the* entity in a
> PreUpdate callback method is valid. One example might be implementing a
> wiki.
> On each update of a page you may want to update the version and update a
> lastUpdatedBy attribute with the userid that made the update. The PreUpdate
> callback is a fairly logical place to make such a change.
> Absent a compelling reason why an application can't update the entity in a
> callback method I'm inclined to view this as a good improvement.
> -mike
> On Mon, Sep 22, 2008 at 3:54 PM, Kevin Sutter <> wrote:
>> Hi,
>> I've been talking to MikeD about this and I thought I should get some input
>> from other experts...
>> In the EntityListener methods, we can pass an instance of the entity to the
>> method invocation.  Is it valid for these methods to update this entity
>> instance?  The JPA spec and Pro EJB3 book don't indicate one way or the
>> other.  And, all of the examples cited just show read only usage of the
>> entities passed in.  The spec is clear that you can't utilize EntityManager
>> and Query operations, but it doesn't qualify what you can or can not do to
>> the entity itself.
>> The specific scenario that I am experiencing is a @PreUpdate method is
>> calling a setter method on one of it's attributes.  OpenJPA is getting a
>> little confused with this since this processing is updating the @Version
>> field (when it really doesn't need to).  So, the commit rolls back due to
>> inconsistent @Version values.  And, due to this update-within-an-update, we
>> end up calling the @PostUpdate listener twice for the same entity instance.
>> Like I said, we get kind of confused.
>> Before I open a JIRA to address this problem, I'm wondering whether anybody
>> is reading the spec differently and this should not be allowed.  (BTW, I'm
>> hearing that Hibernate can process this okay, but I have not been able to
>> confirm this.)
>> Comments and discussion welcome.
>> Thanks,
>> Kevin

Simone Gianni            CEO Semeru s.r.l.           Apache Committer
MALE human being programming a computer

View raw message