The test started to fail due to the change of the test code -
it used to NOT
close the entity manager before triggering the fetch group.
That means it's not a regression - to fix the test it should be just
back to its previous state (rev. 6213).
The test was altered to expose the bug, which happened when a fetch
triggered on a detached object.
That bug was fixed as part of work on nested fetch groups (see bug 244124
However this is still happening on WebSphere.
Investigation showed that on WebSphere after the entity manager is
object is still registered in the entity manager's unitOfWork (and the
That is caused by fix to Bug 259993
- em.find() hangs up in some situations on
WebSphere apparently caches EntityManagerImpls - instead of closing
calls em.clear and then return to a cache for future reuse.
The problem was the timing of the clear call - it came when Eclipselink
yet merged uow (in afterComplete).
Fix for Bug 259993
cured this problem but not allowing em.clear() called while
uow is merging to do anything but to clear the cache.
There are several drawbacks to this solution:
1) Objects read in by ValueHolders triggered on detached objects may
identity (uow has no cache);
2) uow is never released - map of clones, etc is held until the uow is
This second point is also the reason for the test failure - the fetch
code verifies if the object is registered in the uow, and if it is
the object is also present in uow's cache.
But currently on WebSphere using jta after em.close() the object is
registered, but is not in the uow's cache.
The suggested solution: if em.clear is called on synchronized uow, and
uow is merging (WebSphere's case) then don't clear the cache, but set
that will cause uow to be released after the merge in afterCompletion is
That would cure both problems listed above.