temporary entity left in the database after being deleted.

[Pawel Veselov <pa...@gmail.com>]

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.

Re: temporary entity left in the database after being deleted.

[Pawel Veselov <pa...@gmail.com>]

Hi Rick.

On Thu, Dec 29, 2011 at 4:45 AM, Rick Curtis <cu...@gmail.com> wrote:

> Try something like this:
>
> E_App temp = new E_App();
> temp.setPrimaryKey(temporaryPK);
> temp = em.merge(temp);
>

Thank you so much, that fixed it, obviously!

-- Pawel.


>
> Thanks,
> Rick
> On Dec 29, 2011 5:47 AM, "Pawel Veselov" <pa...@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.
>

Re: temporary entity left in the database after being deleted.

[Rick Curtis <cu...@gmail.com>]

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" <pa...@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.
>