您可能来这里寻求关于何时使用持久化和何时使用合并的建议。我认为这取决于具体情况:您需要创建新记录的可能性有多大，以及检索持久数据的难度有多大。

让我们假设您可以使用自然键/标识符。

Data needs to be persisted, but once in a while a record exists and an update is called for. In this case you could try a persist and if it throws an EntityExistsException, you look it up and combine the data: try { entityManager.persist(entity) } catch(EntityExistsException exception) { /* retrieve and merge */ } Persisted data needs to be updated, but once in a while there is no record for the data yet. In this case you look it up, and do a persist if the entity is missing: entity = entityManager.find(key); if (entity == null) { entityManager.persist(entity); } else { /* merge */ }

如果你没有自然的键/标识符，你将很难弄清楚实体是否存在，或者如何查找它。

合并也可以用两种方式处理:

如果更改通常很小，请将其应用到托管实体。 如果更改很常见，则从持久化实体以及未更改的数据复制ID。然后调用EntityManager::merge()替换旧的内容。

我在我的实体上得到了lazyLoading异常，因为我试图访问一个会话中的惰性加载集合。

我要做的是在一个单独的请求中，从会话检索实体，然后尝试访问我的jsp页面中的一个集合，这是有问题的。

为了缓解这个问题，我在控制器中更新了相同的实体，并将其传递给我的jsp，尽管我想象当我在会话中重新保存时，它也可以通过SessionScope访问，而不会抛出一个LazyLoadingException，这是示例2的修改:

以下是我行之有效的方法:

// scenario 2 MY WAY
// tran starts
e = new MyEntity();
e = em.merge(e); // re-assign to the same entity "e"

//access e from jsp and it will work dandy!!

持久化和合并是为了两个不同的目的(它们根本不是替代方案)。

(编辑以扩大差异信息)

坚持:

向数据库中插入一个新的寄存器 将对象附加到实体管理器。

走：

找到具有相同id的附加对象并更新它。 如果存在，则更新并返回已附加的对象。 如果不存在，则将新寄存器插入数据库。

persist()效率:

在向数据库插入新寄存器时，它可能比merge()更有效。 它不会复制原始对象。

persist()的语义:

它确保您是在插入而不是错误地更新。

例子:

{
    AnyEntity newEntity;
    AnyEntity nonAttachedEntity;
    AnyEntity attachedEntity;

    // Create a new entity and persist it        
    newEntity = new AnyEntity();
    em.persist(newEntity);

    // Save 1 to the database at next flush
    newEntity.setValue(1);

    // Create a new entity with the same Id than the persisted one.
    AnyEntity nonAttachedEntity = new AnyEntity();
    nonAttachedEntity.setId(newEntity.getId());

    // Save 2 to the database at next flush instead of 1!!!
    nonAttachedEntity.setValue(2);
    attachedEntity = em.merge(nonAttachedEntity);

    // This condition returns true
    // merge has found the already attached object (newEntity) and returns it.
    if(attachedEntity==newEntity) {
            System.out.print("They are the same object!");
    }

    // Set 3 to value
    attachedEntity.setValue(3);
    // Really, now both are the same object. Prints 3
    System.out.println(newEntity.getValue());

    // Modify the un attached object has no effect to the entity manager
    // nor to the other objects
    nonAttachedEntity.setValue(42);
}

这种方法对于实体管理器中的任何寄存器只存在一个附加对象。

对于带id的实体，Merge()是这样的:

AnyEntity myMerge(AnyEntity entityToSave) {
    AnyEntity attached = em.find(AnyEntity.class, entityToSave.getId());
    if(attached==null) {
            attached = new AnyEntity();
            em.persist(attached);
    }
    BeanUtils.copyProperties(attached, entityToSave);

    return attached;
}

虽然如果连接到MySQL merge()可以像persist()一样有效，使用一个调用INSERT和ON DUPLICATE KEY UPDATE选项，JPA是一个非常高级的编程，你不能假设这将是任何地方的情况。

这两种方法都会将实体添加到PersistenceContext中，区别在于之后如何处理实体。

Persist获取一个实体实例，将其添加到上下文中，并使该实例被管理(即将跟踪实体的未来更新)。

Merge返回与状态合并的托管实例。它确实返回存在于PersistenceContext中的内容或创建实体的新实例。在任何情况下，它都会从提供的实体复制状态，并返回一个托管副本。传入的实例不会被管理(你所做的任何更改都不会成为事务的一部分——除非你再次调用merge)。不过您可以使用返回的实例(托管实例)。

也许一个代码示例会有所帮助。

MyEntity e = new MyEntity();

// scenario 1
// tran starts
em.persist(e); 
e.setSomeField(someValue); 
// tran ends, and the row for someField is updated in the database

// scenario 2
// tran starts
e = new MyEntity();
em.merge(e);
e.setSomeField(anotherValue); 
// tran ends but the row for someField is not updated in the database
// (you made the changes *after* merging)
      
// scenario 3
// tran starts
e = new MyEntity();
MyEntity e2 = em.merge(e);
e2.setSomeField(anotherValue); 
// tran ends and the row for someField is updated
// (the changes were made to e2, not e)

场景1和3大致相同，但在某些情况下，您可能希望使用场景2。

persist(entity)应该与全新的实体一起使用，将它们添加到DB(如果实体已经存在于DB中，则会抛出EntityExistsException)。

应该使用Merge(实体)，如果实体被分离并被更改，则将实体放回持久性上下文中。

可能持久是生成INSERT sql语句和合并UPDATE sql语句(但我不确定)。

关于merge的更多细节将帮助你使用merge over persist:

Returning a managed instance other than the original entity is a critical part of the merge process. If an entity instance with the same identifier already exists in the persistence context, the provider will overwrite its state with the state of the entity that is being merged, but the managed version that existed already must be returned to the client so that it can be used. If the provider did not update the Employee instance in the persistence context, any references to that instance will become inconsistent with the new state being merged in. When merge() is invoked on a new entity, it behaves similarly to the persist() operation. It adds the entity to the persistence context, but instead of adding the original entity instance, it creates a new copy and manages that instance instead. The copy that is created by the merge() operation is persisted as if the persist() method were invoked on it. In the presence of relationships, the merge() operation will attempt to update the managed entity to point to managed versions of the entities referenced by the detached entity. If the entity has a relationship to an object that has no persistent identity, the outcome of the merge operation is undefined. Some providers might allow the managed copy to point to the non-persistent object, whereas others might throw an exception immediately. The merge() operation can be optionally cascaded in these cases to prevent an exception from occurring. We will cover cascading of the merge() operation later in this section. If an entity being merged points to a removed entity, an IllegalArgumentException exception will be thrown. Lazy-loading relationships are a special case in the merge operation. If a lazy-loading relationship was not triggered on an entity before it became detached, that relationship will be ignored when the entity is merged. If the relationship was triggered while managed and then set to null while the entity was detached, the managed version of the entity will likewise have the relationship cleared during the merge."

以上所有信息都摘自Mike Keith和Merrick Schnicariol的“Pro JPA 2掌握Java™Persistence API”。第六章。分段分离与合并。这本书实际上是作者专门介绍JPA的第二本书。这本新书比前一本有许多新信息。我非常推荐那些将认真参与JPA的人阅读这本书。我很抱歉匿名发布了我的第一个答案。