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 >>> >>> >> >
