Perhaps a change in Cayenne is due. E.g. if a cached snapshot is not the one object was committed against, we still need to dispatch the event as "invalidate" or something.
Andrus > On Dec 18, 2015, at 3:00 AM, Matt Watson <m...@swarmbox.com> wrote: > > Thanks Andrus, > > I was playing with this some more today, and it is calling > ObjectStore.snapshotsChanged. When everything is working correctly, I can see > the proper objects in “modifiedDiffs”, however when the object I expect to be > in the modifiedDiff is not there, I can confirm that it was previously tossed > out because of the “snapshot version changed, don’t know what to do”. I'm > going to spend more time trying to figure out why this is occurring, but I’m > pretty sure its coming from a “Select" of that object (resolving a > ToOneFault). > > Since these “snapshot issues” are likely the culprit, does anyone have > suggestions for how to avoid these? Is there a bad pattern I’m using within > my code, that I should look for and replace? > > Thanks, > Matt > > > >> On Dec 16, 2015, at 10:09 AM, Andrus Adamchik <and...@objectstyle.org> wrote: >> >> Hi Matt, >> >>> On Dec 15, 2015, at 11:37 PM, Matt Watson <m...@swarmbox.com> wrote: >>> It is my understanding that if more than one ObjectContext has the same >>> DataObject, when changes to that object are committed, the other context >>> that has that same object will automatically be updated with the changes. >>> But this does not seem to be happening for me. >> >> Within the same VM, yes, unless you turn it off explicitly. Try running in >> debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and >> see if it is called. >> >>> The specific scenario, is that I have two different people receiving >>> product to the same PurchaseOrderLine. If they both bring in that >>> PurchaseOrderLine before anything has been received, the “receivedQuantity” >>> on that POL starts out at 0 (ZERO). When person A scans a box, the >>> POL.receivedQuantity increments to 1, and then increments to 2 when he >>> scans another. Then if person B scans a box, their POL still thinks the >>> “receivedQuantity” is ZERO and it increments it to 1. So what I have in the >>> database is a POL with receivedQuantity 1, but there are actually >>> InventoryTransactions showing that it should be at 3. >> >> So I presume you commit after every scan? Again, this would mean the events >> should be propagated and merged into objects. >> >>> Not sure if this is related but we often see in the log during a commit -> >>> "snapshot version changed, don't know what to do…” >> >> This can be related ... if this happens, IIRC Cayenne does not generate a >> snapshot event. >> >>> I read the Cayenne docs here >>> (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>) >>> that it does not recommend using synchronization for a large number of >>> users (peer Contexts), however I tested this with only 2 and still >>> experience the issue. And now that I have just reread that documentation, >>> I may have misunderstood that the object is automatically updated, and that >>> instead the Context is notified of the changes via an event, but if I am >>> not listening that event (& handling), then that could be why the other >>> Context does not have the updated information on that object. >> >> In addition to poor performance characteristics, snapshot syncing is prone >> to various race conditions (e.g. an object property may get refreshed via an >> event, but then immediately overwritten from the UI), so its use is rather >> limited. I'd personally turn it off and use some other approach, e.g. >> optimistic locking in combination with query cache (query cache which was >> discussed a few days ago here [1]. >> >> Andrus >> >> [1] >> http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache >> >> >
