I'm investigating a serious performance problem in my OSGi-based application which is using Eclipselink as persistence provider for JPA classes. The problem appeared very suddenly after a version update of the application but did not disappear after a rollback. The configuration has not changed. There's a non-trivial amount of data in the system (Eclipselink's internal registry counts around 2 million entities), but that amount grew rather smoothly.
Among the sources I'm investigating is the change detection policy. Currently, Eclipselink is using DeferredChangeDetectionPolicy (as determined with a debugger), which is stated to be less efficient than AttributeChangeTrackingPolicy and also doesn't seem to make sense to me for my scenario.
Now, I have explicitly configured Attribute Change Tracking Policy for my persistence unit. Also, it should be the default anyway for JPA annotated classes.
Before the problem existed, I had no idea which change detection policy was in use. I'm investigating the possibility that Eclipselink switched it for some reason that is unknown to me. Is there any such reason?
EclipseLink will use deferred change tracking when weaving isn't available/configured. Have you configured weaving (dynamic or static). If you're running on Equinox you can use dynamic [1] or static. On other OSGi frameworks you're limited to static weaving.
--Shaun
[1] http://wiki.eclipse.org/EclipseLink/Examples/OSGi/Equinox_Byte_Code_Weaving