我正在调查基于 OSGi 的应用程序中的严重性能问题，该应用程序使用 Eclipselink 作为 JPA 类的持久性提供程序。该问题在应用程序版本更新后突然出现，但回滚后并没有消失。配置没有改变。系统中的数据量相当大(Eclipselink 的内部注册表约有 200 万个实体)，但该数据量的增长相当平稳。
我正在调查的来源之一是 change detection policy 。目前，Eclipselink 正在使用 DeferredChangeDetectionPolicy(由调试器确定)，据说它的效率低于 AttributeChangeTrackingPolicy，而且对我来说似乎没有意义。场景。
现在，我已经为我的持久性单元显式配置了属性更改跟踪策略。另外，无论如何，它应该是 JPA 带注释的类的默认值。
在问题出现之前，我不知道正在使用哪种更改检测策略。我正在调查 Eclipselink 出于某种我不知道的原因切换它的可能性。有这样的理由吗？
最佳答案
当编织不可用/配置时，EclipseLink 将使用延迟更改跟踪。您是否配置了编织(动态或静态)。如果您在 Equinox 上运行，则可以使用动态 [1] 或静态。在其他 OSGi 框架上，您仅限于静态编织。
--肖恩
[1] http://wiki.eclipse.org/EclipseLink/Examples/OSGi/Equinox_Byte_Code_Weaving
关于java - 尽管另有配置，Eclipselink 何时使用 DeferredChangeDetectionPolicy？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6100351/