BatchFetchPolicy.clone() cause memory leak and ConcurrentModifcationException

[fataOT]

The latest EL update to 2.7.10 introduced a memory leak within our application.
We think the root cause for this leads back to an old bug in BatchFetchPolicy.clone() (https://bugs.eclipse.org/bugs/show_bug.cgi?id=491349)

In 2.7.10 the initialization of the "dataResults" map has been shiftet to the constructor

    public BatchFetchPolicy(BatchFetchType type) {
        this.type = type;
        this.dataResults = new HashMap<Object, List<AbstractRecord>>();
        this.dataResults.put(this, new ArrayList<AbstractRecord>());
    }

So every created BatchFetchPolicy will have a dataResults-Map with the BatchFetchPolicy as an entry.

Now let's look at the clone() method

    public BatchFetchPolicy clone() {
        BatchFetchPolicy clone = null;
        try {
            clone = (BatchFetchPolicy)super.clone();
        } catch (CloneNotSupportedException error) {
            throw new InternalError(error.getMessage());
        }
        if (clone.dataResults != null) {
            clone.dataResults.put(clone, clone.dataResults.get(this));
        }
        return clone;
    }

The clone()-method will create a BatchFetchPolicy which will use the same map reference as the original BatchFetchPolicy.
The result of one clone() call is, that the dataResults map will have 2 entries, then 3, 4, ....
As a result of this, the garbage collection is unable to remove those objects.

The ConcurrentModifcationException from the referenced bug has the same origin.
The attributeExpressions list ist not a deep copy so all cloned BatchFetchPolicies will use the same list which can cause the ConcurrentModifcationException in case of heavy usage of QueryHints.BATCH within different threads/EntityManagers

Open questions:

• What is the benefit for using the clone() method at all? Which data is necessary to remember?
• Is there any reason to not deep copy the data?
• Why is the dataResults map always initialized but only used for BatchFetchType.IN (we do not use BatchFetchType.IN at all, so our workaround for the memory leak is to only initialize the dataResults for BatchFetchType.IN)

[fataOT]

The memory leak has already been fixed by #1245