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