Hi Malte!
puh, that's a pretty tricky puzzler.
You flush and detach. At this point the 'data' instance has the information
that it got inserted.
Since the entity got detached it also has no further information that the
transaction got rolled back.
So technically I can understand what happens.
I also do not think this is ruled out by the spec. Otoh it's surely also not
defined that it should work.
So my guess is that you are hitting a rather unspecified area of JPA.
What if you just move the detach to a finally block?
Would that probably solve your problem?
LieGrue,
strub
> Am 24.04.2017 um 17:55 schrieb Malte <malte.neum...@googlemail.com>:
>
> Hello all!
>
> In a special situation, I'll get a wrong EntityExistsException.
>
> I've extract the problem to a simple project (attached).
>
> I do this:
> try {
> entManager.persist(data);
> entManager.flush();
> entManager.detach(data);
>
> doOtherDBCallsWithError();
>
> entManager.getTransaction().commit();
> } catch (Exception e) {
> entManager.getTransaction().rollback();
>
> entManager.getTransaction().begin();
> entManager.persist(data);
> entManager.getTransaction().commit();
> }
>
> If doOtherDBCallsWithError throws an Exception, it is not possible to persist
> the object in the catch-block. The second persists throws
> "org.apache.openjpa.persistence.EntityExistsException: Attempt to persist
> detached object "de.test.model.Test-1". If this is a new instance, make sure
> any version and/or auto-generated primary key fields are null/default when
> persisting." If I use merge instead, the object will also not persist. If I
> remove the detach, everything works.
>
> Is this a bug or is the call order persist-flush-detach-commit against the
> specification?
>
> Best regards,
> Malte
> <test.zip>
