Hi Andrus,
ok, setting PersistenceState.HOLLOW works. So easy :-)
I'm subscribing to your argument to generally refreshing entire collections for
consistency. But this isn't about a simple CMS with a few blog posts. 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.
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). Of
course everything would be easier if the asynchronous threads could just all
operate on the same ObjectContext and there would be no need to refresh
anything in the first place.
And no, I don't want auto-synchronization. I do need the isolation of changes
in the general case.
Maik
> Am 22.02.2017 um 14:33 schrieb Andrus Adamchik <[email protected]>:
>
> Hi Maik,
>
> Like I said, I personally hate chasing individual object changes, and rather
> deal with refreshing entire collections. Refreshing individual objects
> quickly leads to cases that are nearly impossible to handle in the code, as
> modified objects may no longer match the criteria for being in a given
> collection.
>
> Say in a CMS you have a list of published articles. Another context changes
> published status of an article from true to false. You refreshed your object,
> but it is still in the published list. So now you need to filter that list
> in-memory. But the list still doesn't see any new articles that got
> published, so you need to track insert events, and so on.
>
> So instead of micro-optimizations with shared snapshot cache, you should use
> queries with cache groups and query cache. They get refetched when a cache
> group is flushed in response to an object commit. So technically you are not
> reusing the snapshot cache, but it really doesn't matter. The benefit you get
> in code simplicity, consistency, and often performance, always outweighs
> that. Besides this approach is cluster-friendly.
>
>> However, this page says "By default when a single ObjectContext commits its
>> changes, all other contexts in the same runtime receive an event that
>> contains all the committed changes", so perhaps there may be a way to send
>> objectcontexts this event regardless?
>
> Not sure if you are convinced by the argument above :). But yeah, you can
> turn context syncing back on, and get auto-synchronization. So when you set
> Constants.SERVER_CONTEXTS_SYNC_PROPERTY to true (or rather don't set it to
> false), does it handle the refreshing the way that you want?
>
> Andrus
>
>
>> On Feb 22, 2017, at 4:02 PM, Musall, Maik <[email protected]> wrote:
>>
>> Hi Andrus,
>>
>> this works, but requires using the newly localObject()ed object instance to
>> be used after refreshing. Any other references of that object in the
>> original context will still hold the unchanged values.
>>
>> Btw, I found the page I mentioned:
>> https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts
>>
>> <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>
>> I used the mentioned property setting in there to turn of synchronization of
>> ObjectContexts, for the listed reasons. However, this page says "By default
>> when a single ObjectContext commits its changes, all other contexts in the
>> same runtime receive an event that contains all the committed changes", so
>> perhaps there may be a way to send objectcontexts this event regardless?
>>
>> Maik
>>
>>
>>> Am 22.02.2017 um 07:37 schrieb Andrus Adamchik <[email protected]>:
>>>
>>> Since we mostly focused on policy- and event-based *query* caches, the API
>>> for managing caching of individual objects is not as streamlined, but here
>>> it is FWIW:
>>>
>>> T myObject = ..;
>>> ObjectContext context = myObject.getObjectContext();
>>> ObjectId id = myObject.getObjectId();
>>>
>>> // kick it out, unset ObjectContext (side effect - sets ObjectId to null)
>>> context.getGraphManager().unregisterNode(id);
>>>
>>> // restore ObjectId.. it was set to null in the call above (which we
>>> probably should change)
>>> myObject.setObjectId(id);
>>>
>>> // get a fresh fault
>>> myObject = context.localObject(myObject);
>>>
>>> Andrus
>>>
>>>
>>>> On Feb 21, 2017, at 11:54 PM, Musall, Maik <[email protected]> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have an application using a big shared snapshot cache. Objects freshly
>>>> instantiated in an ObjectContext get their attributes populated based on
>>>> the snapshot cache at the time, and keep them during the context's
>>>> lifetime, which is also what I want. (Last week I found a page on
>>>> cayenne.apache.org <http://cayenne.apache.org/> explaining this behaviour,
>>>> but I can't find it again. Seems not to live within the linked Guide
>>>> hierarchy.)
>>>>
>>>> In some cases though, I have object instances in ObjectContext 1 which I
>>>> know are getting modified in ObjectContext 2, and I want them to be
>>>> updated after commit in context 1. In EOF, I could call
>>>> oc1.refreshObject(obj), or even oc1.refreshAllObjects(), which will merge
>>>> the new values in from the snapshot cache. Is there any way to do this in
>>>> Cayenne, short of refetching which would cost a roundtrip to the database
>>>> even though I know I already have the current values in the snapshot cache?
>>>>
>>>> (I had a question posted recently about "creating a fault for an
>>>> ObjectId", but this is different because I need the commit in context 2 to
>>>> go through to the database.)
>>>>
>>>> Maik
>
