cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lon Varscsak <lon.varsc...@gmail.com>
Subject Re: Syncing peers in single thread
Date Wed, 16 Sep 2015 18:47:51 GMT
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 <andrus@objectstyle.org>
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 <lon.varscsak@gmail.com>
> 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 <lon.varscsak@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 <
> andrus@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 <mgentry@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.varscsak@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 <
> >>> andrus@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.varscsak@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 <
> >>>>> andrus@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.varscsak@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message