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
