Re: Caching problem?

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed May 24 2006 - 15:01:58 EDT

  • Next message: Andrus Adamchik: "Re: saving BigDecimal with scale issue"

    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 - 15:02:25 EDT