You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Lon Varscsak <lo...@gmail.com> on 2015/08/31 23:47:31 UTC
Syncing peers in single thread
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
Re: Syncing peers in single thread
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <lo...@gmail.com> 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 <an...@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 <lo...@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 <lo...@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 <mg...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: Syncing peers in single thread
Posted by Lon Varscsak <lo...@gmail.com>.
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 <an...@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 <lo...@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 <lo...@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 <mg...@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: Syncing peers in single thread
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <lo...@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 <lo...@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 <an...@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 <mg...@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 <lo...@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 <lo...@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 <lo...@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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
Re: Syncing peers in single thread
Posted by Lon Varscsak <lo...@gmail.com>.
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 <lo...@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 <an...@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 <mg...@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 <lo...@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 <lo...@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 <lo...@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
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>>
>>
>
Re: Syncing peers in single thread
Posted by Lon Varscsak <lo...@gmail.com>.
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 <an...@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 <mg...@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 <lo...@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 <lo...@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 <lo...@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
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: Syncing peers in single thread
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mg...@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 <lo...@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 <an...@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 <lo...@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 <lo...@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
>>>>>
>>>>>
>>>
>>>
>>
Re: Syncing peers in single thread
Posted by Michael Gentry <mg...@masslight.net>.
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 <lo...@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 <an...@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 <lo...@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 <lo...@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
> > >>
> > >>
> >
> >
>
Re: Syncing peers in single thread
Posted by Lon Varscsak <lo...@gmail.com>.
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 <an...@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 <lo...@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 <lo...@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
> >>
> >>
>
>
Re: Syncing peers in single thread
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <lo...@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 <an...@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 <lo...@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
>>
>>
Re: Syncing peers in single thread
Posted by Lon Varscsak <lo...@gmail.com>.
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 <an...@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 <lo...@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
>
>
Re: Syncing peers in single thread
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <lo...@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