> Am 22.02.2017 um 19:39 schrieb Andrus Adamchik <and...@objectstyle.org>:
>
>
>> On Feb 22, 2017, at 6:55 PM, Musall, Maik <m...@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
