JPA混淆(托管与非托管实体)

Question

我正在研究一个网络项目,试图了解一遍又一遍地做这种事情的最佳方法:

• 从DB中读取对象A.
• 稍后,阅读另一个对象(B)
• 在DB中更改A和B(作为事务的一部分 - 写入所有更改或不写入)

老式的JDBC类型方式不是问题,但JPA正在努力.

我需要在那里明确划分数据库更改发生的位置,并且根据我的观察,对管理实体的任何更改都将在下次EntityManager.commit()调用时被修改(无论事务是否在更改之前明确开始) ).正确？

那么确保所有实体永远不会被管理并且总是更好merge()吗？

我发现自己必须在这两个例子中做出决定:

RepaintAction1

User user = getUser(); //non-managed entity
Car car = getCar(123); //non-managed

car.setColor("Red");
user.setLog("Paints car red");

dao.update(car, user);

RepaintDAO1

entityTransaction.begin();
entityManager.merge(car);
entityManager.merge(user);
entityTransaction.commit();

要么:

RepaintAction2(这与RepaintAction1相同,但与托管实体相同)

User user = getUser(); //managed entity
Car car = getCar(123); //managed

car.setColor("Red");
user.setLog("Paints car red");

dao.update(car, user);

RepaintDAO2

entityTransaction.begin();
entityManager.flush();
entityTransaction.commit();

第一个我不介意,但我必须忽略管理实体的一些优势(哪些？).在第二个我不喜欢交易范围不明确的方式(以及如何处理回滚？).

但这些是唯一的选择(例如,有没有办法使用托管实体明确划分交易)？处理这个问题的最佳方法是什么？

我为这么做而道歉,但是我经历了很多没有帮助的文档,我甚至不确定我所观察到的是正确的.

Answer 1

1. 对托管实体的任何更改都将在下次EntityManager.commit()调用时进行修改(无论是否在更改之前显式启动了事务).正确？ 正确.

2. 那么确保所有实体永远不会被管理并且总是更好merge()吗？ 并非总是(或者他们不会让选择保持开放)但这很常见,所以示例1是你最常找到的.

3. 实际上不需要刷新示例2,提交将隐式刷新.

4. 如何处理回滚？如果提交失败,则持久性提供程序将回滚.如果应用程序容器收到系统异常,则会回滚现有事务.

5. 管理实体的优势？延迟加载(没有LazyInitializationException).此外,它会跟踪您的更改内容,因此您不会合并太多/几个实体.

6. 有没有办法使用托管实体明确划分交易？我不清楚你有什么不清楚的.也许你的意思是不清楚是什么发生了变化,因为实体的变化发生在开始/提交边界之外.但是对于合并分离的实体也是如此,您可以更好地控制合并的内容,但是您没有确切地看到哪些属性发生了变化.

7. 处理这个问题的最佳方法是什么？通常,您的Web请求由事务性服务(spring/ejb ...)处理.实体经理将由容器注入.通常,这些实体管理器是事务范围的(仅在事务发生时生效),因此在调用服务之前它们不存在.这意味着传递给它们的所有实体都不受管理.事务将在服务结束时提交(或回滚).

注意:如果您考虑使用托管实体,这通常与长期存在的EntityManagers一起使用.如果这样做,请注意EntityManagers不是线程安全的.