Re: 3.0 cache documentation

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon May 11 2009 - 20:42:02 EDT

  • Next message: Andrus Adamchik: "Re: reverse engineering partially changed schema"

    On May 7, 2009, at 9:14 AM, Aristedes Maniatis wrote:
    > On the object cache page you discuss Memory Management with the
    > shared and local caches.
    > 1. Should this section be moved to the parent page since it applies
    > both to query and object caches? That is, is the memory space of
    > 10,000 shared between object and query cache?

    Actually no. It only applies to the object cache. Query cache may have
    its own memory management considerations, but with a variety of
    options with it, I didn't delve into details. In any event until we
    start using a single cache mechanism for object and query cache, I'd
    stay the memory management is separate for both as well.

    > 2. If an object is stored in the shared cache by one context and
    > another context uses it, will localObject() need to be called on it
    > to move it to the correct context or is that all handled
    > automatically?

    This is transparent. Shared cache actually stores DataRows, but since
    one of my goals with this doc was to avoid too many low level details,
    I omitted that mention.

    > 3. If objects are always synchronised between local caches is
    > refreshing ONLY needed when thinking about multiple instances of the
    > application in separate JVMs? If so, this could be made even clearer
    > in the refreshing section.
    >
    > "Object caching happens behind the scenes, so the only case when
    > users need to worry about object cache is when an object gets stale
    > and needs to get refreshed"
    >
    > maybe instead:
    >
    > "Object cache refreshing is done automatically for you be Cayenne,
    > so the only case users need to worry about refreshing manually is
    > when you are running multiple instances of the application in
    > separate JVMs. In that case you have the following options:"

    We can clarify this, but then we should also mention that the data in
    DB can get updated independently from Cayenne or Java apps (e.g. via a
    SQL load). I.e. there's more than one way for it to get stale, so
    again I omitted the details, but we can add them if we want.

    > 4. I'd like to understand a little better the relationship between
    > query cache and object cache. For example, will Cayenne every
    > perform a query against the database and then throw away the results
    > it gets because it sees that the objectIds are already in the object
    > cache? That is, does a query which hits the db always result in a
    > refresh of the object cache?

    Since 3.0 the answer to the last question is definite yes. It used to
    be configurable via 'setRefreshingObjects(..)', still with the
    advances in the query cache, this option became redundant and got
    deprecated.

    > And, if the query is cached and therefore no SELECT is issued, will
    > the results sometimes include hollow objects which will then be
    > faulted? Perhaps the object cache was full and those objects had
    > been expired.

    Unless I am missing something, I don't think this scenario is
    possible. With the shared object cache (that uses LRU map) even if the
    DataRow is expired, the cached query list will provide its own
    DataRows (DataRows are not subject to uniqing unlike DataObjects);
    with a local object cache (that uses weak reference map) the fact that
    an object is cached in the list will prevent it from being garbage
    collected.

    > So, whether the object cache is refreshed will depend on whether a
    > query hits the db or comes from cache?

    Correct.

    Andrus



    This archive was generated by hypermail 2.0.0 : Mon May 11 2009 - 20:42:36 EDT