Two new configuration options are introduced in EclipseLink 2.1.  One such option is to use an EXISTS with a sub-select instead of a JOIN.  This should not result in duplicate rows, so avoid issues with DISTINCT.

Another option is to load the target objects using a IN clause containing the source query object's primary keys.  This would also work with cursors, but as the limitation of requiring custom SQL support for composite primary keys, and produces a large dynamic SQL query.

A new BatchFetchType enum will be define and the usesBatchReading flag will enhance to setBatchFetch allowing for JOIN, EXISTS or IN.  This option will also be added to ObjectLevelReadQuery, rolling up the current 4 batch reading properties into a new BatchFetchPolicy, also moving them up from ReadAllQuery to allow ReadObjectQuery to also specify nested batched attributes.  A new BatchFetch annotation and query hint will be added.

The IN option will query a batch of the target objects using an SQL IN clause containing the key values.  For a 1-1 the foreign keys from the source rows will be extracted, if these are the primary keys of the target, they will first be filtered by checking the cache for each object.  The remaining keys will be split into batches of a query configurable size, defaulting to 256.  For composite keys the multi array SQL syntax for ((key1, key2), (...)) IN ((:key1, :key2), (...)) will be used.  Only some databases support this syntax, so composite primary keys will only be supported on some databases.  For 1-m or m-m the source rows do not contain the primary keys of the target objects.  The IN will still be supported, but will be based on join the source query as in JOIN (or maybe EXISTS?) for the set of keys.  For cursors the IN size will default to the cursor pageSize, and each cursor page will be processed separately.