Currently I'm using Tapestry...but I'm not sold on that yet. I feel like a lot of frameworks are shying away from state...and I'm a state lover. :P So for now, while my testing base is in Tapestry, I'm just focusing on porting all of our frameworks from WO/EOF to Cayenne (skipping the WO parts).
Usually the contexts are per component, the data that is shared that I need synchronization on, is within the context of a session. I'm not really worried about synchronizing to other sessions (although obviously that's the nature of how EOF and it appears Cayenne works...and that's probably good). -Lon On Mon, Sep 14, 2015 at 6:35 AM, Andrus Adamchik <[email protected]> wrote: > Hi Lon, > > This is probably doable, but won't be clean or easy. Maybe instead we can > rethink the scope of your ObjectContexts. So a few questions: > > 1. What are you using for the web framework? Is that Tapestry or something > else? > 2. What is the current scope of ObjectContexts? Is that ObjectContext per > component per user session? > > Andrus > > > > On Sep 10, 2015, at 4:19 PM, Lon Varscsak <[email protected]> > wrote: > > > > 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 <[email protected]> > > 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 < > [email protected]> > >> 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 <[email protected]> > >>> 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 <[email protected] > > > >>>> 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 < > >>> [email protected]> > >>>>> 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 <[email protected] > > > >>>>>> 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 < > >>>>> [email protected] > >>>>>>> > >>>>>>> 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 < > [email protected]> > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >
