cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff de Vries <jdevr...@pfrog.com>
Subject Re: Caching problem?
Date Fri, 26 May 2006 17:19:14 GMT
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?
>>
>>
>

Mime
View raw message