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 Thu, 10 Sep 2015 19:05:57 GMT
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