Re: Caching/Concurrency Questions

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Jun 08 2004 - 21:22:42 EDT

  • Next message: PaulC.177094..loglines.com: "Re: Caching/Concurrency Questions"

    Hi PaulC,

    Shared cache actually stores DataRows. DataRows are maps of values
    representing object snapshots. Snapshots from the cache are used for a
    number of things. Mainly to lazily build UPDATE queries and to lazily
    resolve to-one relationships.

    On the other hand, when you retrieve *lists* of objects (i.e. by
    running a query explicitly, or when resolving a to-many relationship),
    Cayenne still has to hit the database, as it needs to know *which*
    snapshots match the query criteria (and it does not attempt to suck the
    whole DB in memory).

    BTW, in the upcoming M7 milestone caching of query results is also
    supported
    (http://objectstyle.org/cayenne/lists/cayenne-devel/2004/06/0002.html
    ). But it will be explicit, while snapshots use is works behind the
    scenes whenever possible.

    Andrus

    On Jun 8, 2004, at 4:26 PM, PaulC.177094..loglines.com wrote:
    > Hi,
    >
    > I have just started investigating Cayenne and am very impressed so
    > far.
    >
    > I am trying to understand the caching/concurrency model between
    > separate
    > DataContexts (within the same VM). I roughly understand the concept
    > that a
    > DataContext provides an isolated transactional container for the
    > retrieved
    > object graph but am not sure I understand how this interacts with the
    > shared
    > object caching.
    >
    > I put together a test script which did (roughly) the following:
    >
    >
    > - Create 2 DataContexts
    > - Retrieve same object into each DC
    > - In DC #1
    > change object property
    > - Commit DC #1
    > - In DC #2 change object property
    > (to different value)
    > - Commit DC #2
    >
    > When I ran this it looks like the
    > objects are fetched into each DC separately (2 db calls) and changes
    > in each
    > DC are isolated and committed to the DB individually without updating
    > the
    > other DC (resulting in stale data in each DC after the other commits).
    >
    > The Domain does have Shared Cache enabled and I was wondering if this
    > is the
    > expected behaviour and if so how the shared caching actually works.
    >
    > Using
    > optimistic-locking on the appropriate property I do then get an
    > exception
    > thrown on the second commit (as expected)
    >
    > Thanks, PaulC
    >
    >



    This archive was generated by hypermail 2.0.0 : Tue Jun 08 2004 - 21:22:51 EDT