cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musall, Maik" <m...@selbstdenker.ag>
Subject Re: A way to refreshObject()
Date Wed, 22 Feb 2017 19:42:02 GMT

> Am 22.02.2017 um 19:39 schrieb Andrus Adamchik <andrus@objectstyle.org>:
> 
> 
>> 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 did test adding a new object to a to-many relationship of an object, and that became visible
after setting the root object HOLLOW, which is what I would expect. You think I need to do
more testing on relationships regarding this?

>> 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. 

Well, in my case I can ensure that there is only one reader thread, which is waiting on the
writing subthreads to complete execution, and which then will call the refreshAllObjects()
itself. So, no problem there. (I did have to design the application so that only one thread
would be operating on one editingContext in EOF at the time, even for read-only access.)

> 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?

Would work only if read access is really restricted to those entry point objects and anything
traversed from there. It would be easy to introduce mistakes by holding on to references in
#2 that didn't get the update. Also, activity in #2 would be limited to read-only operations
even on objects that aren't touched by #1.

Maik


Mime
View raw message