我一直认为在事务之前(在entityManager.getTransaction().begin()
之前)获取的实体与持久化上下文分离(同时使用相同的实体管理器来获取实体以处理事务)。事实上,每次我管理事务时,我都必须明确合并在它之外获取的实体。如果我没有,则更新不会反映在数据库中。
但是最近,我和一位经历过这种情况的同事进行了讨论。他必须明确地分离在事务之前获取的每个实体,以避免更新数据库。
我们的代码之间的唯一区别是我的persistence.xml
文件是2.0版本,而他的版本是1.0。但他在他的代码中使用了JPA 2.1。这是出现这种奇怪行为的原因还是我在这里缺少的东西?
我们都使用Hibernate作为实现。
答案 0 :(得分:2)
PersistenceContext可能有两个范围:
<强> TRANSACTIONAL-SCOPE 强>
仅在EntityManager由容器管理时发生。在这种情况下,只要当前事务存在,当前的PersistenceContext就会处于活动状态。
<强> EXTENDED-SCOPE 强>
当EntityManager由应用程序管理(默认)或容器管理(EntityManager需要注释:@PersistenceContext( type=PersistenceContextType.EXTENDED)
)时发生。
长话短说:EXTENDED-SCOPE意味着只要您的bean存在,当前的PersistenceContext就会存在。
答案 1 :(得分:1)
事情如何以及如何自动合并到事务上下文中取决于几个因素。正在使用的JPA实现,持久性上下文范围以及正在使用的事务隔离。没有看到整个环境,就无法轻易回答。我假设你的应用程序允许非事务性读取(脏读,幻读,不可重复读),因此你被允许&#34;决定是否要合并。 另一种解释可能是你的应用程序代码混合了几个持久化上下文,因此要求你将在一个持久化上下文中读取的实体合并到另一个持久性上下文(你启动TX的那个)。
答案 2 :(得分:0)
他们将被管理。任何更改都将在下一个flush
内反映到数据库中。事务提交会立即刷新,同时还会受到事务前操作排队的更改。