Adding the prefetch did indeed solve the problem, though I'm a little
uneasy with having to go through my code adding prefetchs to get proper
behavior.
I'll see if I can get a smaller test case that I can post.
Thanks for your help!
Jeff
Andrus Adamchik wrote:
I am not sure why are you not seeing the fresh values (do you have
clustering and serialized sessions?), but there is an easy way to fix
it - add Listing relationship prefetch to the query that retrieves
alerts.
Andrus
On May 23, 2006, at 8:15 PM, Jeff de Vries wrote:
Any more thoughts or things I can try to get this to work?
Looking at the SQL log, it looks like I oversimplified the
description of the problem (sorry). There is actual another table
involved, Listing, and the status that is being updated is in
Listing, not in Alert, though the Listing is being accessed through
the Alert (Alert has a foreign key referencing the Listing). So,
let me try again to describe the sequence of steps that are used to
update the database:
1) Using a given Listing, we SELECT all Alerts that refer to that
Listing. (In the case I'm looking at there is only one Alert).
2) Start transaction (i.e. there is a (unnecessary?) commit after
the previous SELECT)
3) INSERT a new Alert that references the existing Listing (note
that at this point the Listing has not been updated yet, i.e. it
still has the old status) and the Person the Alert is addressed to.
4) UPDATE the first Alert to indicate it has been processed (i.e.
set a 'seen' column to 'true')
5) UPDATE the status in the Listing to the new status (this is the
thing we're seeing the old version of later)
6) COMMIT changes.
Later, we do the following:
1) SELECT all Alerts addressed to this Person (which includes the
new Alert created in step 3 above; this is also the query to which
we added setRefreshingObjects = true, which now looks unnecessary
since we did get the new Alert even before making that change)
2) For each Alert, display the status of the Listing referenced by
that Alert. Note that at this point in the SQL log I don't see any
SELECT statements trying to retrieve Listing data, so I'm guessing
Cayenne thinks it already knows all the associated Listings and
their statuses. It looks like it is the relationship between Alert
and Listing that needs to be refreshed?
3) The status for the Listing associated with the new Alert still
shows the value it had before it was updated in step 5 above.
So, is it possible that when the new Alert is created it is pointing
at the original version of the Listing (I'm talking about the
in-memory objects, not the rows out in the database), but when the
Listing is updated the in-cache version isn't getting updated? Or
the in-cache version is getting updated, but the Alert is pointing
at a stale Listing object?
