Yeah, the app reacting to an occasional inconsistency is probably a better approach then trying to synchronize many things at once.
Andrus > On Dec 28, 2015, at 6:25 PM, Matt Watson <m...@swarmbox.com> wrote: > > I just read about Optimistic Locking. Maybe that a strategy to use for a > scenario like this. > > Matt >> On Dec 24, 2015, at 12:45 AM, Andrus Adamchik <and...@objectstyle.org> wrote: >> >> 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 >>>> >>>> >>> >> >
