Re: Caching problem?

From: Marcin Skladaniec (poldwusmoko..mail.com)
Date: Fri May 19 2006 - 23:24:30 EDT

  • Next message: Jeff de Vries: "Re: Caching problem?"

    I'll ask few questions, just to be sure:
    - are you using named queries (ie. when fetching the alerts)
    - are you using the same context when creating alert and when
    checking for the alerts ?

    If the latter try to use different context. And to be 100% sure in
    the second query do query.setCachingPolicy(SelectQuery.NO_CHACHE);
    See if that helps.

    Regards
    Marcin

    On 20/05/2006, at 11:35 AM, Jeff de Vries wrote:

    > It didn't make any difference. (I was so sure it *would* make a
    > difference I ran it three times and double-checked everything each
    > time).
    >
    > 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?
    >
    > Thanks for the help!
    > Jeff
    >
    > Marcin Skladaniec wrote:
    >> You can try:
    >>
    >> DataContext dc = DataContext.getThreadDataContext();
    >> SelectQuery query = new SelectQuery(alert_subclass);
    >> ...
    >> query.setRefreshingObjects(true);
    >> ...
    >> List result = dc.performQuery(query);
    >>
    >> Regards
    >> Marcin
    >>
    >> On 20/05/2006, at 8:05 AM, Jeff de Vries wrote:
    >>
    >>> I get the following compile error (I'm using Cayenne 1.2):
    >>> The method performQuery(Query) in the type DataContext is not
    >>> applicable for the arguments (SelectQuery, boolean)
    >>>
    >>> I tried to find something equivalent for Cayenne 1.2 but didn't
    >>> recognize anything.
    >>>
    >>>
    >>> Gentry, Michael (Contractor) wrote:
    >>>> Could you try: List result = dc.performQuery(query, true); And
    >>>> see if it works better? Thanks, /dev/mrg -----Original
    >>>> Message----- From: Jeff de Vries [mailto:jdevrie..frog.com]
    >>>> Sent: Friday, May 19, 2006 12:18 PM To: cayenne-
    >>>> use..ncubator.apache.org Subject: Re: Caching problem? It's
    >>>> pretty straightforward. In the following code Person is the
    >>>> parent, and Alert is the child. There are actually many Alert
    >>>> classes (I'm using Cayenne STI), so the specific Alert class
    >>>> we're interested in is passed as a parameter. Also, I forgot to
    >>>> mention that if we shut everything down, and then restart, we do
    >>>> see the modified status (presumably because Cayenne really had
    >>>> to go back to the database to get the data for the child list). /
    >>>> ** * Finds all Alerts of the given type sent to the given person
    >>>> * *..aram person * Person to find Alerts for * @param
    >>>> include_hidden * If true, include hidden alerts as well *..aram
    >>>> alert_subclass * Class of alert to search for *..eturn List of
    >>>> alert objects, of given type, for the given person */ protected
    >>>> static List findFor(Person person, boolean include_hidden, Class
    >>>> alert_subclass) { DataContext dc =
    >>>> DataContext.getThreadDataContext(); SelectQuery query = new
    >>>> SelectQuery(alert_subclass); query.setQualifier
    >>>> (ExpressionFactory.matchExp("toReceiver", person));
    >>>> query.andQualifier(ExpressionFactory.matchExp("deleted", new
    >>>> Boolean (false))); if (!include_hidden) query.andQualifier
    >>>> (ExpressionFactory.matchExp("hidden",new Boolean (false)));
    >>>> query.addOrdering("createDate",false); List result =
    >>>> dc.performQuery(query); return result; } On May 19, 2006, at
    >>>> 6:05 AM, Gentry, Michael ((Contractor)) wrote:
    >>>>> Jeff, could you post the code where you are doing the second
    >>>>> query? Thanks! /dev/mrg -----Original Message----- From: Jeff
    >>>>> de Vries [mailto:jdevrie..frog.com] Sent: Friday, May 19, 2006
    >>>>> 12:09 AM To: cayenne-use..ncubator.apache.org Subject: Caching
    >>>>> problem? Simplified version: I have a parent table and a child
    >>>>> table, where the child table has a parent_id column and a
    >>>>> status column. I change the status in one of the child records
    >>>>> and commit the change. Later, I ask for the child records for
    >>>>> the given parent record, but the child record that I get back
    >>>>> on which I changed the status still has the *old* status
    >>>>> instead of the new status. If I look at the database, the child
    >>>>> record does have the new status (and in fact I can see the
    >>>>> update and commit as soon as I commit the child record change).
    >>>>> Why is the parent still seeing the old child status? An
    >>>>> additional note is that I'm not using parent.getChildArray()
    >>>>> but rather a SelectQuery(Child) that matches toParent to the
    >>>>> parent I'm interested in. (This is in Cayenne 1.2B2 using
    >>>>> PostgreSQL 8.1) Thanks, Jeff
    >>



    This archive was generated by hypermail 2.0.0 : Fri May 19 2006 - 23:25:17 EDT