Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] Bug 405518 - 2 jpa tests failed with "no-weave" option

Checked the patch into both trunk and 2.5.

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).



Back to the top