cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: A way to refreshObject()
Date Wed, 22 Feb 2017 18:39:21 GMT

> On Feb 22, 2017, at 6:55 PM, Musall, Maik <maik@selbstdenker.ag> wrote:
> 
> Hi Andrus,
> 
> ok, setting PersistenceState.HOLLOW works. So easy :-)

Ah great. We all just learned a new Cayenne trick :) 

IIRC this also whacks to-many relationships, and those require a query to get restored, as
we can't guess relationship composition  (another reason why I gave up on managing graph refreshing
in memory).

> I have cases where I have spent considerable resources to fetch large object graphs into
memory, and then I'm sending off a few threads doing middle-duration asynchronous processing
on a few objects, have them update an computed attribute and come back. When I'm receiving
the message that object x is finished updating, it wouldn't make sense to refresh the entire
object graph, let alone repeat any expensive db roundtrips.

Fair enough.

> However, I do have cases where I want to refresh the entire graph of objects in one ObjectContext,
but I still want to make use of the snapshots to save the fetches if they tend to be expensive.
This is how I'm doing it now, is this correct?
> 
> 	for( Object obj : context.getGraphManager().registeredNodes() ) {
> 		((DataObject)obj).setPersistenceState( PersistenceState.HOLLOW );
> 	}
> 
> The assumption below all this of course is that I can only have one thread writing in
one ObjectContext, although I can read on one ObjectContexts with several threads at once
(like when using .parallelStream() on collections). 

This will work, but will not be atomic (your readers will be consuming data in the middle
of invalidation ), and potentially will cycle through too many objects. 

Here is another idea. Assuming context #1 is where the changes happen, context #2 is where
the reads occur. When you need a full refresh, create context #3, then transfer only the "entry
point" objects from #2 via "localObject" and then switch the readers to #3 at some point and
let the rest of the graph gradually inflate from cache. Again, no idea if that's workable
in your setting. Logically readers should not care if they get a separate copy of the graph,
as long as it is read-only. No?

Andrus




Mime
View raw message