We recently upgraded to Toplink 10.1.3.4.0 and noticed a change in behavior. We perform a ReadAllQuery with associated batch read attributes in order to power a listing of objects in the ui. Each of these is linked to navigate into the object details.
Previously, I believe the BatchValueHolder was replaced with a QueryBasedValueHolder when navigating into the object details (either when entering cache or leaving cache), and so only the related objects associated with one object were read. After the upgrade, the ValueHolder is no longer replaced, so the related objects are unnecessarily read for all the objects originally in the ReadAllQuery.
Is this expected behavior, for a BatchValueHolder to be preserved in cache after hard references are removed, and then used on a subsequent request? If so we will have to rethink our batch read attribute strategy.
10.1.3 is a very old release, you may want to upgrade.
The behavior did not change, the purpose of batch read attributes has always been to read all of the related objects when any related object is accessed. You should normally only batch something you intend to access.
What may have changed is that previously if the object was already in the cache, then the relationship would not be refreshed with the BatchValueHolder, so would not get the benefit of batching if it was already cached. 10.1.3.4 most likely now refreshed the cached QueryBasedValueHolder with the BatchValueHolder. If the object was not in the cache, the behavior would still be the same, the object in the cache would be built with a BatchValueHolder, and whenever any of the related objects is accessed, all of the related objects would be batch read.