Not using clusters (yet). We are serializing some data, but just the
ID, not the objects themselves (and in this case it's the user ID, not
any of the IDs for the objects we're fetching in the problem case).
I'll try adding the prefetchs.
Could the fact that these objects have cyclical relationships be
confusing the updating of these cached objects? The changes are making
it to the database, so it's something about the cached objects
themselves (I think) that is the problem.
BTW, we tried to write a (kludgy, non-DB) workaround for this problem
(this is a very serious problem for us right now), but immediately ran
into another field in the Listing object that had an old value instead
of the new value. In this case, it was the foreign key in the Listing
pointing back to the Alert that "won" (which is where we get the cycle -
Alerts have a foreign key pointing back to Listing they belong to, and a
Listing has a foreign key pointing to the (single) "winning" Alert).
If all of this doesn't work, I guess I'll try to distill things down to
a smaller test case that I can submit for scrutiny.
Thanks again,
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?
>>
>>
>
This archive was generated by hypermail 2.0.0 : Wed May 24 2006 - 16:21:57 EDT