JPA(EclipseLink)单表继承下父类A实例转子类B失败问题

1. JPA实体类型的不可变性：Java对象的类型在实例化后无法动态改变，JPA单表继承模型（通过dtype鉴别器列区分子类）中，EntityManager加载实体时会根据鉴别器列的值确定实例的Java类型，一旦实例被加载到持久化上下文（一级缓存），其类型就固定了。
2. 持久化上下文的残留引用：即使修改了数据库中的dtype值并刷新，且清除了二级缓存，但在同一个事务内，EntityManager的持久化上下文仍然保留着最初加载的A类型实例引用。当调用em.find(B.class, oldId)时，EntityManager会优先从持久化上下文中查找对象，找到的是A实例，强制转换为B类型时必然抛出类转换异常。
3. Eclipselink缓存清除的局限性：你调用的initializeAllIdentityMaps()仅清除了二级缓存（服务器端会话缓存），而持久化上下文（一级缓存）与当前EntityManager绑定，除非调用em.clear()彻底清空，否则原有实例不会被移除。但即使调用em.clear()，同一事务中重新查询时，受事务隔离性影响，可能仍无法读取到刚修改的dtype值，导致实例化结果还是A类型。

• 跨事务拆分操作：
  1. 在第一个事务中：加载A实例，修改dtype为b，提交事务并关闭EntityManager。
  2. 在第二个新事务中：使用新的EntityManager调用em.find(B.class, oldId)查询，此时持久化上下文无残留，Eclipselink会根据数据库更新后的dtype值实例化B类型对象。
• 通过JDBC直接修改并重置上下文：
  1. 绕过JPA，用JDBC执行SQL语句直接更新数据库对应记录的dtype字段为b。
  2. 调用em.clear()清空当前持久化上下文，同时调用二级缓存清除方法（如initializeAllIdentityMaps()）。
  3. 在同一事务中（确保事务隔离级别能读取到刚修改的数据）重新调用em.find(B.class, oldId)，此时会从数据库重新加载并实例化为B类型。
• 遵循JPA设计规范的替代方案：
  不修改现有实例的类型，而是创建新的B实例，复制原A实例的所有属性，删除原A实例，将新B实例的ID设置为原ID（需确保实体ID生成策略支持手动指定，比如@GeneratedValue(strategy = GenerationType.TABLE)或允许手动赋值），最后保存B实例。这种方式避免了类型转换问题，更符合JPA设计理念。

内容的提问来源于stack exchange，提问作者jane doe