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 <[EMAIL PROTECTED]> 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 >
