Actually I see how that would work now. You mention deadlocking, would there be a way in the application framework (assuming I keep it multi-threaded) to wait for the event manager to finish? So that at least my request-response loop is properly refreshed before generating a response.
-Lon On Thu, Sep 10, 2015 at 1:13 PM, Lon Varscsak <lon.varsc...@gmail.com> wrote: > I don't think that works for me. One component is not aware that anything > is happening. I don't want constant round trips to the db every time I > refresh a page on something that is cached. In our case, it's highly > unlikely the data is changed externally. > > Andrus, can you elaborate on your ObjectStore.setDataRowCache idea? > > > On Thu, Sep 10, 2015 at 12:05 PM, Andrus Adamchik <and...@objectstyle.org> > wrote: > >> 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 >> >>>>> >> >>>>> >> >>> >> >>> >> >> >> >> >