Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of michael.d.dick@gmail.com
 designates 209.85.198.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=Oths0gFMF6aUi1ukPMUgNxMQk6onZeDvHiy+H2JU4h3v14ky45DkYE7+JpI8SCWKWp
         N9/XHr5ZsVY/3TiT/1ow8Lblz1oe/VIjKUk2C6jYqeduFJObJ4bxC3fH57D3gbZcVHx0
         DdeXth+3CcTyCDezo6Eid5WX/vuXbyZjRrzHw=
Message-ID: <72c1350f0809221546y76db776x1ae57edfc0e4b034@mail.gmail.com>
Date: Mon, 22 Sep 2008 17:46:59 -0500
From: "Michael Dick" <michael.d.dick@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: Updates to entities via Lifecycle callback methods
In-Reply-To: <89c0c52c0809221354i50247207ic78645faa8f15980@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_391_28023001.1222123619817"
References: <89c0c52c0809221354i50247207ic78645faa8f15980@mail.gmail.com>

------=_Part_391_28023001.1222123619817
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
>

------=_Part_391_28023001.1222123619817--