[eclipselink-dev] Bug 405518 - 2 jpa tests failed with "no-weave" option

[Andrei Ilitchev <andrei.ilitchev@xxxxxxxxxx>]

Checked the patch into both trunk and 2.5.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=405518

The bug was caused by my changes made on March 22 as for fix of bug 402391.

The problem consists of two parts (both introduced by my change):
1. ClientSession.executeCall method does not set to null query.accessors 
after the call is finished;
2. ForeignReferenceMapping.valueFromRowInternal method sets accessors 
obtained from the source query into the target query.

That breaks with SessionBroker because the source query may be for 
Employee (which is mapped to Oracle db) and the target - for Address 
(which is mapped to MySQL). That's what broke the tests.

However there are more problems: after the source query is done with the 
connection it might be released (which is always the case if the source 
query executed through ServerSession). Now target query picks up 
connection from the source query - and that released connection is 
potentially closed, or used by a different thread in a different 
transaction.


The fix is simple - to undo these two wrongs:
1. ClientSession.executeCall should set query.accessors to null 
immediatelly after the call is finished (as it used to be before my fix);
2. ForeignReferenceMapping.valueFromRowInternal doesn't pass accessors 
from source to target query (as it used to be before my fix) - unless 
source query uses ResultSetAccessOptimization (that was introduced in 
enhencement 402391).

Note that ResultSetAccessOptimization will still suffer from the 
original problem that broke the tests: if that optimization is used then 
the call is not finished after session.executeCall has returned and 
therefore in SessionBroker case the original problem that broke the 
tests occurs.
However now the problem occurs only in case of 
ResultSetAccessOptimization - and only target query uses it, too.
Note that setting of accessors is required in this case - otherwise 
there is a risk to run out of connections (ResultSetAccessOptimization 
keeps connection until objects are built).

Thanks,

Andrei