EntityManager操作顺序(EntityManager operations order)

 我最近遇到了一个有趣的问题。 我在项目JPA + Hibernate + EJB中使用。 该问题涉及在同一事务中保存和删除实体。 使用的数据库表具有在两列上定义的唯一约束。 
 
 我所做的是删除实体调用 
 
entityManager.remove();
 
 然后，新实体在与唯一约束中使用的列关联的两个属性中添加相同的值，但在其他属性中使用不同的值： 
 
entityManager.persist();
 
 这两个操作在单个事务中执行，并按照上述顺序执行。 先移除，再加上第二。 然而，似乎在违反唯一约束时以颠倒的顺序执行操作。 看起来在删除前一个实体之前添加了新实体。 
 
 显然，我可以打电话 
 
entityManager.flush()
 
 删除后，然后不违反约束。 但是，在这种情况下，数据会在整个事务提交之前保存到数据库中。 这不是一个理想的行为。 如果在刷新之后出现任何问题，并且事务将被标记为回滚，则无论如何都将删除该实体。 
 
 我认为操作顺序与添加到事务中的操作顺序相同。 从我的例子可以看出事实并非如此。 
 
 删除后没有刷新或提交事务有没有办法解决问题？ 
 
 谢谢。 

I have run into interesting issue recently. I use in the project JPA + Hibernate + EJB. The issue concerns saving and deleting entities in the same transaction. Database table which is used has an unique constraint defined on two columns. 
 
What I do is removing entity calling 
 
entityManager.remove();
 
then the new entity is added with the same values in two properties associated with columns used in the unique constraint but different values in other properties using:
 
entityManager.persist();
 
Those two operations are carried out in a single transaction and are executed in the order as presented above. Removal first, addition second. However it seems that the operations are executed in the inverted order as unique constraint is violated. It looks like the new entity is added before removing the previous one.
 
Obviously, I can call
 
entityManager.flush()
 
after removal and then constraint is not violated. However in this case the data is saved to the database before the whole transaction commits. That is not a desirable behavior. If anything goes wrong after flush and transaction will be marked for rollback, the entity will be deleted anyway.
 
I thought that order of operations is the same as they were added to the transaction. From my example it turns out that it is not.
 
Is there any way to solve the issue without flushing or committing the transaction after delete?
 
Thank you. 

原文：https://stackoverflow.com/questions/20284027