我将解释为什么这种情况不应该发生,为什么我们需要分离的实体。
考虑您正在进行JTA事务(JPA需要对此事务进行支持)和访存a
。现在,您可以a.getB()
在此事务中调用(1)(即实体受a
管理),或者在a
分离时调用(2)。
:现在,根据您的事务隔离级别,您可能会看到或可能不会看到其他事务在做什么。例如,如果您具有SERIALIZABLE隔离级别,那么a.getB()
即使该行在并发事务中被删除,您也将成功获取。如果该行已被删除并且您的事务看到该行,则意味着您的数据库不一致(没有外键)或您使用了错误的事务隔离级别。
:实体a
已分离。当LazyInitializationException
抛出a时,对我来说,您a.getB()
为确保应用程序中的一致性而调用得太晚了(因为a
不再管理)。为了解决该问题,您只需在仍然管理实体时就更早地调用它。不会发生NPE。
为什么我们需要DETACHED STATE?好吧,我们需要一个不跟踪对实体实例的更改的状态。为什么?
:假设您在EJB层中收到一个实体(具有持久身份),并且没有分离状态(意味着应该管理所有实体)。但是我们需要在持久化实体之前进行验证。如果该实体将被自动管理,则其更改将自动保存到DB。因此,引入了这种新状态。
:您在EJB层中收到一个实体,您只需要从该实体更新10个字段中的5个即可。如果该实体自动进入托管状态,则所有10个字段都将保留。在这种情况下,解决方案是获取一个受管实体,并仅更新该实体中的5个字段。