Andrus,
Thanks for the explanation - I am strill trying to get the hang
of the concepts.
Just to clarify my understanding - if a single database
record (DataRow) is instantiated into a object graph in two different DataContexts
(through a query) are the corresponding DataObjects linked in any way, and
is there any way a DataContext can be notified that a contained object has
been modified & committed in another DataContext other than trying to commit
with optimisitic locking enabled for the appropriate properties and catching
the exception ?
Thanks again.
Paul
--- Andrus Adamchik <andru..bjectstyle.org
wrote:
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 - 22:41:06 EDT