Interesting, my own stack trace before the fix looked very similar to
yours, even though it was caused by a different sequence of events:
1. A.getB() in the user code
2. When B is fetched, its 'postLoad' callback would call B.getAArray()
3. When an A is resolved, it is incorrectly merged with its cached
snapshot (even though its state corresponds to the snapshot state, and
the merge should be avoided)
4. When B is attached to A during merge, B is resolved from snapshot,
so its postLoad is called again, and step #2 is repeated.
I fixed #3 for RelationshipQueries. Didn't touch anything related to #4.
Now looking at your stack, seems like it is looping between #3 and #4
(skipping #2 that generated a RelationshipQuery)... Wonder how to
reproduce that condition? Maybe you can post a root of the stack, i.e.
the point that triggers the first fault resolution?
In any event, the culprit seems to be this line that trips a fault, so
I may check the history to see what changed in this code since M4:
at
org
.apache.cayenne.access.ObjectDiff.getArcSnapshotValue(ObjectDiff.java:
144)
at org.apache.cayenne.access.DataRowUtils
$2.visitToOne(DataRowUtils.java:188)
Andrus
On Dec 7, 2008, at 10:16 PM, Tore Halset wrote:
> On Dec 7, 2008, at 17:26, Andrus Adamchik wrote:
>
>> Tore, I committed a fix (essentially undoing ~60% of CAY-1138) to
>> both trunk and M5 tag. Could you please try it out before we create
>> the new artifacts?
>
> Sorry, but the latest trunk did not fix the problem. I will have to
> work more on this tomorrow.
>
> - Tore.
>
>
This archive was generated by hypermail 2.0.0 : Mon Dec 08 2008 - 01:25:22 EST