Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of curtisr7@gmail.com designates
 74.125.83.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMnJ+BcQA5_q6FBJnE=sX22DYcZSRk4tD6qwcyASyusgoKLcbQ@mail.gmail.com>
References: 
 <CAMnJ+BcQA5_q6FBJnE=sX22DYcZSRk4tD6qwcyASyusgoKLcbQ@mail.gmail.com>
Date: Thu, 29 Dec 2011 06:45:21 -0600
Message-ID: 
 <CAP=qHCvkOrhFJoJGR1JwCNpVH=_VduAFv=y=2t-fCzUSfUX4Zw@mail.gmail.com>
Subject: Re: temporary entity left in the database after being deleted.
From: Rick Curtis <curtisr7@gmail.com>
To: users@openjpa.apache.org
Content-Type: multipart/alternative; boundary=bcaec52c6a5f473b3404b53a7d23

--bcaec52c6a5f473b3404b53a7d23
Content-Type: text/plain; charset=ISO-8859-1

Try something like this:

E_App temp = new E_App();
temp.setPrimaryKey(temporaryPK);
temp = em.merge(temp);

Thanks,
Rick
On Dec 29, 2011 5:47 AM, "Pawel Veselov" <pawel.veselov@gmail.com> wrote:

> Hi.
>
> I'm not sure what I'm doing wrong here. I'm creating a temporary entity,
> within transaction, deleting the entity before committing. I need that
> temporary entity in the database during the transaction though... My code
> is roughly doing this:
>
> EntityManager em; // have it
> E_App temp = new E_App();
> temp.setPrimaryKey(temporaryPK);
> em.merge(temp);
> em.flush();
> // the temporary entity is in the database, as I wanted (verified)
> // do other crazy stuff now, not touching temp instance in any way
> // (except from side direct DB queries that don't modify any managed
> columns)
> em.remove(temp);
> em.flush(); // I added that line in hope it might make a difference, but it
> doesn't
> // some other stuff, also changes persistence context
> em.getTransaction().commit();
>
> The problem is that temp shows up in the database after commit.
>
> There is a statement in the spec that says that if you call remove() on a
> new entity, it's a no-op. I agree it should be, but I don't think new and
> merged entity qualifies for being "new". I tried to trace this down, and
> from what I can see, BrokerImpl.delete(Object,OpCallbacks) gets <null> from
> getStateManagerImpl() for that object, passing it as a second arg into
> delete(Object, StateManagerImpl, OpCallbacks), which effectively makes it a
> no-op.
>
> Thank you,
>  Pawel.
>

--bcaec52c6a5f473b3404b53a7d23--