cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Syncing peers in single thread
Date Mon, 14 Sep 2015 13:35:12 GMT
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
View raw message