I second that. Combined with query caching and refreshing of certain cache groups on commit, you can get the best of both worlds - minimizing DB trips and fresh data on demand.
Andrus > On Sep 10, 2015, at 10:00 PM, Michael Gentry <mgen...@masslight.net> wrote: > > Hi Lon, > > I almost always go back to the database and fetch fresh data instead of > relying on potentially stale in-memory data in these situations. (I did > the same with EOF, too.) Another good reason to fetch fresh data is in > case the DB was updated outside of the currently running application (DBA > did it, batch job, separate application, you are running clustered, etc). > > mrg > > > On Thu, Sep 10, 2015 at 1:35 PM, Lon Varscsak <lon.varsc...@gmail.com> > wrote: > >> Yes, there is a specific reason. :) So let's say I have a component on a >> page that has a reference to a Company object, yet I also have an >> EditCompany component which has it's own copy of the same Company in a peer >> context. When the user clicks save there, the entire page is refreshed, >> including the original component holding onto Company. If the update to >> that company object is non-deterministic, I will end up with a page that >> displays the "old" data. >> >> I have had other situations, even with in the same block of code I've used >> a peer context to do some work...but I don't have an example off the top of >> my head. >> >> -Lon >> >> On Wed, Sep 9, 2015 at 11:09 PM, Andrus Adamchik <and...@objectstyle.org> >> wrote: >> >>> But why, is there a specific reason? I mean the responses themselves take >>> time to be transferred to the browser, so there's a lag there. So a small >>> lag in syncing on the server side seems acceptable in most scenarios. Or >> do >>> you have some special enforced ordering of responses? >>> >>> Andrus >>> >>>> On Sep 10, 2015, at 12:04 AM, Lon Varscsak <lon.varsc...@gmail.com> >>> wrote: >>>> >>>> There are just some times where we currently assume (using EOF) that >>> after >>>> commit, that all peer contexts are synced. At a minimum, I would need >> to >>>> know that before I generate a response in a web application, that these >>>> contexts are synced. >>>> >>>> -Lon >>>> >>>> On Sun, Sep 6, 2015 at 11:15 PM, Andrus Adamchik < >> and...@objectstyle.org >>>> >>>> wrote: >>>> >>>>> Doing so is possible by binding a custom ObjectStoreFactory in DI >>>>> container and overriding 'ObjectStore.setDataRowCache' method in >>>>> ObjectStore subclass that the factory would create. However I am >> afraid >>>>> this will end up with deadlocks if more than one ObjectContext can >>> commit >>>>> at the same time. >>>>> >>>>> So could you elaborate why you need synchronous peer sync? >>>>> >>>>> Andrus >>>>> >>>>>> On Sep 1, 2015, at 12:47 AM, Lon Varscsak <lon.varsc...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Hey all, >>>>>> >>>>>> I know that Cayenne sync's peer object contexts on a separate thread, >>> but >>>>>> for my case this doesn't work. I need to know that when committing, >>> that >>>>>> the peer synchronization happens immediately after the commit. >>>>>> >>>>>> How would I pull this off? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Lon >>>>> >>>>> >>> >>> >>