I like using REST and keeping state on the client (e.g. the browser) :) But Tapestry 5.x is actually has very decent page state management facilities. You probably know that yourself, but @Persist annotation allows you keep a variable stored in a page+session scope. So one solution for your synchronization problem is to share page ObjectContext with all the child components. This avoids synchronization issue all together.
The simplest way to implement it is to pass the context from the page down to components using bindings. But I am sure this may get out of hand pretty quickly. Alternatively you may store the context for the duration of requests in a Cayenne-provided ThreadLocal (or create your own ThreadLocal for that purpose). A superclass of your pages might take its session context and bind it to request thread . (I haven't tried it actually, but I am going from this T5 docs page: https://tapestry.apache.org/page-life-cycle.html ) : public abstract MySuperPage { // @Persist means session context. // You may actually create per-request contexts if you want. // It is not that expensive in Cayenne. @Persist protected ObjectContext pageContext; @PageAttached public void onStart() { if(pageContext == null) { // init it somehow } BaseContext.bindThreadObjectContext(pageContext); } @PageDetached public void onFinish() { // perhaps clean it up form any unocmmitted stuff: pageContext.rollbackChanges(); BaseContext.bindThreadObjectContext(null); } } Then components can reference the context as ObjectContext c = BaseContext.getThreadObjectContext(); Andrus > On Sep 16, 2015, at 2:47 PM, Lon Varscsak <[email protected]> wrote: > > 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
