Re: Best way to inform (and handle cached object refreshing) of externally-updated database records?

From: Mike Kienenberger (mkienen..laska.net)
Date: Mon Nov 22 2004 - 14:45:26 EST

  • Next message: Mike Kienenberger: "Re: Best way to inform (and handle cached object refreshing) of externally-updated database records?"

    Andrus Adamchik <andru..bjectstyle.org> wrote:
    > Then how about turning off shared cache all together ("Use Shared Cache"
    > checkbox for DataDomain). This will put Cayenne in a "1.0 mode" with each
    > DataContext having its own cache. This way new DataContexts will start
    > empty, and will be filled with fresh data as you run queries or resolve
    > relationships.
    >
    > [Also if you go with this option, I suggest reducing "max number of
    > objects" for the DataDomain cache from 10000 to something smaller, as this
    > will now be multiplied by the number of DataContexts].

    This is the strategy I currently have implemented: If I detect an external
    change, I invalidate all objects.

                
    dataContext.invalidateObjects(dataContext.getObjectStore().getObjects());

    I perform this check in

            DataContext aDataContext =
    CustomBasicServletConfiguration.getDefaultContext(request.getSession());

    which I now use instead of BasicServletConfiguration.getDefaultContext().

    This has the advantage of "updating" a live session at every web request
    (and it should only happen once a day). I'm not sure of the implications
    of one session invalidating objects in all other active sessions. Reading
    the source indicates that new objects won't be touched, but makes me think
    that any changes in a modified object would be lost. Would this be true?

    Your idea of completely non-shared data contexts is an interesting one. My
    concerns would be that the data would never be updated for long-running
    sessions (our administrative users are generally logged as the same session
    all day). I'm also unclear what would happen when I import an object from
    another session using context.localObjects(). I'm guessing that there'd be
    no guarantee that the object reflected what was in the database?

    Maybe for my needs, a combination of these techniques makes the most sense.

    Use a non-shared data context, then invalidate all objects in that context
    when changes are detected as the first step in retrieving a session's
    DataContext. I'm fairly certain that I never make a change during a
    request/response cycle without either committing or rolling back that change
    before sending back a response.

    Thanks. You've given me a new strategy to consider which has some
    unexpected benefits (guarantees that after sessions expire, all database
    objects are "garbage collected").

    -Mike



    This archive was generated by hypermail 2.0.0 : Mon Nov 22 2004 - 14:43:46 EST