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 rolled
back to its 
previous state (rev. 6213).
The test was altered to expose the bug, which 
happened when a fetch group is
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 closed the
object is still registered in the entity manager's 
unitOfWork (and the uow is
not dead).
That is caused by fix to 
Bug 
259993 - em.find() hangs up in some situations on
WebSphere 
7.0.0.1.
WebSphere apparently caches EntityManagerImpls - instead of 
closing them it
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 has not
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 loose
identity (uow has no cache);
2) 
uow is never released - map of clones, etc is held until the uow is 
garbage
collected.
This second point is also the reason for the test 
failure - the fetch group
code verifies if the object is registered in the 
uow, and if it is assumes that
the object is also present in uow's 
cache.
But currently on WebSphere using jta after em.close() the object is 
still
registered, but is not in the uow's cache.
The suggested 
solution: if em.clear is called on synchronized uow, and if the
uow is 
merging (WebSphere's case) then don't clear the cache, but set the flag
that 
will cause uow to be released after the merge in afterCompletion 
is
complete.
That would cure both problems listed 
above.