JPA2实体在完成事务服务层方法后意外地保持管理状态

Question

到目前为止，感谢您的评论！

在控制器和服务impl中注入的实体管理器只是为了调试目的和澄清我的stackoverflow问题而添加的。

我按照Andrei I的建议，添加了一种服务方式：

@Transactional(readOnly=true)
public boolean isManaged(MyEntity myEntity) {
    return em.contains(myEntity);
}

在控制器中，我使用这个新的isManaged（）方法，而不是注入EntityManager。

我重新测试了行为，这仍然是一样的：实体仍然附加在服务方法之外，对实体的更改将持久化到数据库。只有当我离开调用服务方法的控制器方法时，实体才会脱离。

因此，帮助理解这种行为仍然是值得赞赏的！

我有一个非常标准的SpringMVCWeb应用程序，使用JSP视图技术、控制器、服务层方法、实体、SpringCrudepository和JPA2/hibernate作为ORM。服务层方法使用@Transactional注释在事务中运行每个方法。我没有显式配置PersistenceContextType，这意味着我使用默认的PersistenceContextType，即事务。

我的问题是关于实体的托管状态。我的理解是，实体在事务提交后会分离，但事实似乎并非如此！我观察到的行为如下（为了清楚起见，省略了一些代码）：

public class DiningTableController {
    @RequestMapping(value = "/diningTables/{diningTableId}/menuItems", method = RequestMethod.POST)
    public String addMenuItem() {
        1. invoke a service layer method which creates an entity object and invokes save() on it. The service method returns the saved entity
        2. check whether the saved entity is managed. Result: true
        3. change the value of a field of the entity (do not invoke save())
        4. invoke an arbitrary service method in which the entity is not referred to in any way
        5. manually verify in the database that the entity field value is indeed updated as a result of step 3.
        6. check whether the saved entity is managed. Result: true
        7. change the value of a field of the entity to a different value (do not invoke save())
        8. manually verify in the database that the entity field value is NOT updated as a result of step 3.
    }

离开控制器方法后，测试实体是否受管理返回false。如果在调用addMenuItem（）方法之后，我调用了另一个同样调用任意服务方法的控制器方法，那么我仍然看不到步骤7的值。在数据库中（根据eXectation，实体状态现在已分离）。

因此，以下情况似乎是这样的：

• 离开一个服务层方法后，它是事务性的（我可以在日志中看到这会导致提交），实体仍然被管理，这是意想不到的。
• 在离开调用服务层方法的控制器方法后，实体最终变得分离。

一个假设是，它是由自动提交引起的。默认情况下，“自动提交”处于启用状态。我使用以下方法将其关闭：

<prop key="hibernate.connection.autocommit">false</prop>

这会给出警告"WARN：org.hibernate.ejb.Ejb3Configuration-HHH000144：hibernate.connection.autocommit=false破坏了EJB3规范"。日志在其行为中显示自动提交确实被关闭。这不会改变行为。所以我的结论是观察到的行为不是由自动提交引起的。

下面我展示了实际的代码。

@RequestMapping("/")
@Controller
public class DiningTableController {

    private MyEntity savedMyEntity;

    @PersistenceContext
    private EntityManager em;       

    @Autowired
    private MyEntityService myEntityService;
@Autowired
private DiningTableService diningTableService;

    @RequestMapping(value = "/diningTables/{diningTableId}/menuItems", method = RequestMethod.POST)
    public String addMenuItem(
            @PathVariable("diningTableId") String diningTableId,
            @RequestParam String menuItemName, Model uiModel) {

        logger.info("*************BeforeServiceCall (attached=" + em.contains(savedMyEntity) + ")");
        savedMyEntity = myEntityService.doMyEntity();
        savedMyEntity.setSomeValue("ValueChangedOutsideTransaction");
        logger.info("*************ValueChangedOutsideTransaction (attached=" + em.contains(savedMyEntity) + ")");

        DiningTable diningTable = diningTableService.fetchWarmedUp(Long.valueOf(diningTableId));
        uiModel.addAttribute("diningTable", diningTable);

        savedMyEntity.setSomeValue("ValueChangedOutsideTransactionButAfterOtherTransaction");
        logger.info("*************ValueChangedOutsideTransactionButAfterOtherTransaction (attached=" + em.contains(savedMyEntity) + ")");

        return "redirect:/diningTables/" + diningTableId;
    }
}



@Service("diningTableService")
@Repository
@Transactional(rollbackFor = StateException.class)
public class DiningTableServiceImpl implements DiningTableService {
    final Logger logger = LoggerFactory.getLogger(DiningTableServiceImpl.class);

    @Autowired
    private MyEntityRepository myEntityRepository;

    public MyEntity doMyEntity() {
        MyEntity myEntity = new MyEntity(5L, "ValueInitially");
        MyEntity savedMyEntity = myEntityRepository.save(myEntity);
        logger.info("*************ValueInitially");
        savedMyEntity.setSomeValue("ValueChangedInsideTransaction");
        logger.info("*************ValueChangedInsideTransaction");
        return savedMyEntity;
    }

}




public interface MyEntityRepository extends PagingAndSortingRepository<MyEntity, Long> {

}



@Entity
@JsonIdentityInfo(generator = ObjectIdGenerators.IntSequenceGenerator.class, property = "@id") 
@Getter @Setter
public class MyEntity implements Serializable {
    private static final long serialVersionUID = 1L;

    @Id
    private Long id;

    private String someValue;

    public MyEntity() {
    }

    public MyEntity(Long id, String someValue) {
        this.id = id;
        this.someValue = someValue;
    }

}

Answer 1

Spring为EntityManager使用代理，该代理在使用时为当前线程注册EntityManager。Springs事务管理查看是否已经有一个线程绑定的EntityManager，在您的情况下是由于控制器内部的注入。

现在，由于已经存在线程绑定的alreadyaEntityManager，因此不会为事务创建一个新的线程绑定（正如您所期望的那样），但会重用现有的线程绑定。现在，由于重用了现有事务，因此事务不会关闭/销毁EntityManager，而是将其保留，它只会提交事务。

要修复它并获得真正的事务范围的持久性上下文行为，不要将EntityManager注入到控制器中，而是在服务上创建一个方法来检查对象是否被管理。正如@Andreii在他的回答/评论中建议的那样。这将为每个事务创建一个新的EntityManager，并且不会重用已经绑定线程的EntityManager

Answer 2

您检查实体是否仍处于管理状态时出错。你不应该把它们注射到你的控制器里。如果您想这样做，请向您的服务发出另一个请求并将其签入（类似于service.isManaged（mySavedEntity））。