When does Eclipselink use DeferredChangeDetectionPolicy although configured otherwise?

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 DeferredChange开发者_JAVA技巧DetectionPolicy (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

What version of EclipseLink are you using? What did you upgrade from, and to?

Are you having this problem on all of your entities? If so, then Shaun's answer is likely .

What exactly is the problem that you are experiencing? Are you sure that it is with deffered change tracking, and not elsewhere.

If you are experiencing this on 1 or a few of your entities, did you add/change any mappings during your upgrade?