openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: Updates to entities via Lifecycle callback methods
Date Mon, 22 Sep 2008 22:46:59 GMT
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

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.


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

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