Are you setting the display group up with a data source like this?

            dataSource = new EODatabaseDataSource(editingContext(), 
entityName());
            
((EODatabaseDataSource)dataSource).fetchSpecification().setRefreshesRefetchedObjects(refreshesRefetchedObjects());



On 2011-12-12, at 1:56 PM, Michael Gargano wrote:

> After more testing and playing today.  It seems that the refresh of the 
> ERXBatchingDisplayGroup is sporadic at best.  I tried using just the fetch() 
> and the status field never updated, setting the qualifier to the current 
> qualifier seems to work more often then not, but it still does not work 
> consistently.  However, forcing a page refresh in one browser still seems to 
> consistently update the other browser.  At the end of the day, I just don't 
> want the display group to cache any of the records on this page.
> 
> Thanks.
> -Mike
> 
> 
> On Dec 12, 2011, at 2:35 PM, Chuck Hill wrote:
> 
>> 
>> On 2011-12-09, at 3:54 PM, Michael Gargano wrote:
>>>> 
>>>>> If I reload the page on one machine, it updates the status and then 
>>>>> subsequently the other machine refreshes with the correct status, but I 
>>>>> need to poke it.  I don't understand why it works fine on the individual 
>>>>> machines when I'm logged in only once and acts like this when I have two 
>>>>> browsers refreshing the same data.  The page generates a new EC.  I'm 
>>>>> guessing it's some kind of weird locking issue, but I can't figure out 
>>>>> what's locking.  I'm using optimistic locking and on top of that, these 
>>>>> are only reads.
>>>> 
>>>> 
>>>> One EOF stack or multiple?  Try turning on SQL logging to see what is 
>>>> going on with the database.
>>> 
>>> One EOF stack to the database where this is occurring, multiple in the app 
>>> itself, and in production (not the case here) load balanced app servers.
>>> From what I can see in the SQL logs... when it works the way I expect it 
>>> to, I see the fetch for the full object.  When the refresh is just hanging 
>>> out, I see two queries.  
>> 
>> I suspect these are coming from different places in the code.  You should be 
>> able to modify ERXAdaptorChannelDelegate to lock a trace of where the 
>> fetches come from.
>> 
>> 
>>> One that gets the count using the user qualifier and then a select on the 
>>> id's for the batch that I'm currently on.
>> 
>> That is the ERXBatchingDisplayGroup refreshing.  Can you change the 
>> underlying fetch spec to refresh refetched objects?
>> 
>> 
>>> I don't see the fetch for the full object in these cases.  That's what's so 
>>> confusing.  I can't figure out what would be different.  The editing 
>>> context is getting created at the page level (and cached in an ivar), does 
>>> that get cached per page or per thread?  If it's per page could it be 
>>> because they are actually using the same editing context?
>> 
>> 
>> It is per page *instance* and they should not be using the same EC.
>> 
>> Chuck
>> 
>> -- 
>> Chuck Hill             Senior Consultant / VP Development
>> 
>> Practical WebObjects - for developers who want to increase their overall 
>> knowledge of WebObjects or who are trying to solve specific problems.    
>> http://www.global-village.net/products/practical_webobjects
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

-- 
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/products/practical_webobjects







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to