总是有很多与独立实体有关的问题！
首先，它们经常导致LazyInitializationExceptionhibernate。是的，还有另一个持久性提供程序，它们不抛出异常，但是我认为它们在一致性方面存在一些问题。考虑我们有A和B实体，@ManyToOne从A到那里的引用（）B必须为非null。
LazyInitializationException
A
B
@ManyToOne
我们开始了会话，加载了A实例，然后关闭了会话。之后，我们尝试获取对的引用B。并假设另一笔交易只是删除了我们A和B实例。因此，当我们从数据库查询时，我们找不到合适的B实例并获取null！
null
因此违反了我们的合同。某些依赖于a.getB()返回对象的事实的代码 将引发NullPointerException。对于持久性实体，这是不可能的，因为我们在获取对象本身的同一个事务中都进行了延迟加载，因此所有操作都是原子的（当然，如果我们具有适当的事务隔离）。
a.getB()
NullPointerException
当您要将持久性实体和分离的实体存储在一个实体中时，也会出现问题Set。在这种情况下，您应该始终重写equalsand hashCode，通常看起来很尴尬，因为我看不到这样做的真正好方法。
Set
equals
hashCode
要使一个分离的实体重新进入EntityManager您的位置，应使用merge哪个故障。
EntityManager
merge
所以我的问题是：是否存在合理需要分离实体的合理场景？此外，何时需要混合分离的实体和持久性实体并将分离的实体合并为新实体EntityManager？
我将解释为什么这种情况不应该发生，为什么我们需要分离的实体。
考虑您正在进行JTA事务（JPA需要对此事务进行支持）和访存a。现在，您可以a.getB()在此事务中调用（1）（即实体受a管理），或者在a分离时调用（2）。
a
方案1 ：现在，根据您的事务隔离级别，您可能会看到或可能不会看到其他事务在做什么。例如，如果您具有SERIALIZABLE隔离级别，那么a.getB()即使该行在并发事务中被删除，您也将成功获取。如果该行已被删除并且您的事务看到该行，则意味着您的数据库不一致（没有外键）或您使用了错误的事务隔离级别。
方案2 ：实体a已分离。当LazyInitializationException抛出a时，对我来说，您a.getB()为确保应用程序中的一致性而调用得太晚了（因为a不再管理）。为了解决该问题，您只需在仍然管理实体时就更早地调用它。不会发生NPE。
为什么我们需要DETACHED STATE？好吧，我们需要一个不跟踪对实体实例的更改的状态。为什么？
示例1 ：假设您在EJB层中收到一个实体（具有持久身份），并且没有分离状态（意味着应该管理所有实体）。但是我们需要在持久化实体之前进行验证。如果该实体将被自动管理，则其更改将自动保存到DB。因此，引入了这种新状态。
示例2 ：您在EJB层中收到一个实体，您只需要从该实体更新10个字段中的5个即可。如果该实体自动进入托管状态，则所有10个字段都将保留。在这种情况下，解决方案是获取一个受管实体，并仅更新该实体中的5个字段。
