我正在研究基于OSGi的应用程序中的严重性能问题，该应用程序使用Eclipselink作为JPA类的持久性提供程序。在应用程序的版本更新后，问题突然出现，但在回滚后没有消失。配置没有改变。系统中有一些非常重要的数据（Eclipselink的内部注册表大约有200万个实体），但这个数量增长相当顺利。
我正在调查的来源是change detection policy。目前，Eclipselink正在使用DeferredChangeDetectionPolicy（由调试器确定），据说效率低于AttributeChangeTrackingPolicy，对我的情况似乎也没有意义。
现在，我已为我的持久性单元显式配置了属性更改跟踪策略。此外，它应该是JPA注释类的默认值。
在问题出现之前，我不知道哪个更改检测策略正在使用中。我正在调查Eclipselink因为我不知道的某些原因而切换它的可能性。有这样的理由吗？
答案 0 :(得分：1)
当编织不可用/未配置时，EclipseLink将使用延迟更改跟踪。您是否配置了编织（动态或静态）。如果您在Equinox上运行，可以使用动态[1]或静态。在其他OSGi框架上，您只能使用静态编织。
- 肖恩
[1] http://wiki.eclipse.org/EclipseLink/Examples/OSGi/Equinox_Byte_Code_Weaving
答案 1 :(得分：0)
您使用的是哪个版本的EclipseLink？你从什么地方升级到了？
您是否在所有实体上遇到此问题？如果是这样，那么肖恩的回答很可能。
您遇到的问题究竟是什么？你确定这是跟踪变更跟踪，而不是其他地方。
如果您在1个或几个实体上遇到此问题，您是否在升级过程中添加/更改了任何映射？