openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Updates to entities via Lifecycle callback methods
Date Tue, 23 Sep 2008 22:23:13 GMT
Based on this discussion, I have created OPENJPA-732 (
https://issues.apache.org/jira/browse/OPENJPA-732) for this problem.  I also
posted my testcase to the JIRA Issue, if any of you are interested.  I have
also pinged the JPA expert group so that we can properly update the
specification to clarify this usage.  Thanks for the input!

Kevin

On Tue, Sep 23, 2008 at 5:15 PM, Pinaki Poddar <ppoddar@apache.org> wrote:

>
> Yes, PreUpdate() is useful for many purposes (Auditing, for example). But a
> PreUpdate() callback method should be restricted to modify only the basic
> fields of a given entity. If it is allowed to modify its references to
> other
> entities or other second-class objects (e.g. adding removing members of a
> related collection) then that can be a non-trivial (or even non-tractable)
> problem to solve during flush/commit cycle due to re-entrancy.
>
>
> Simone Gianni wrote:
> >
> > 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."
> >
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_overview_pc_callbacks
> >
> > 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.
> >
> > Simone
> >
> > 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 <kwsutter@gmail.com>
> 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   http://www.simonegianni.it/
> >
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Updates-to-entities-via-Lifecycle-callback-methods-tp1110631p1113863.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
>

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