Re: TimeStamp LAG in editing context

Jonathan Rochkind wrote:

> At 10:16 AM 3/6/2003 -0800, you wrote:
> 
>> 2. The lag only affect what happens when an object is first brought 
>> into an editing context.  Regardless of what you do to the lag after 
>> this, the object will not be refreshed.
> 
> 
> Everyone keeps getting confused about this, so we should be precise with 
> our language. You mean "Regardless of what you do to the fetchTimestamp 
> after this..." you don't mean "the lag".  An EOEditingContext has a 
> fetchTimestamp. This is not a lag time, it's a point-in-time timestamp.  
> There is a static method that uses the word 
> 'lag'---setDefaultFetchTimestampLag---this controls what the _initial_ 
> fetchTimestamp for a newly created EC will be----it will be that many ms 
> 'lagged' behind the 'now' time.  But an EOEditingContext individually 
> does not have a 'lag', it has a fetchTimestamp point-in-time, no lag 
> about it.
> 
> Everyone keeps getting confused about this.
> 

Yes, you are correct.  I meant fetchTimestamp.


>> 3. Using a low lag time *and* using a refreshing fetch spec caused a 
>> lot of problems with decrementSnapshotCountForGlobalID and 
>> incrementSnapshotCountForGlobalID.  Someone else said it was OK for 
>> them, so this might only affect inheritance.
> 
> 
> That sucks. Me, I actually turned off snapshot reference counting 
> altogether back in 5.0, because I couldn't figure out what was causing 
> the 'unable to increment/decrement' exceptions. If someone else figured 
> out more of what was causing it, has it been filed as a bug?  One of 
> these days I mean to turn it back on and see if it finally works.  There 
> are definitely very negative memory consequences to turning off snapshot 
> ref counting, like I've done.
> 

I'm pretty certain that was just in 5.0 and fixed in 5.1.  I was never brave 
enough to use 5.0 (and 5.2 is making me nervous, I'm waiting for 5.2.1 :-), but 
it always worked fine for me in 5.1 other than what I noted above.


Chuck



>>
>> Jonathan Rochkind wrote:
>>
>>> [Un-cross-posted from multiple groups; following up just to eof list].
>>> At 10:31 AM 3/6/2003 -0300, Ing.Gaston Blanco wrote:
>>>
>>>> I´m setting the lag in the editing context to 1 , then i create an 
>>>> EC, fetch an object. Then, from a sql terminal i change it, and when 
>>>> i refetch the changes are not reflected in my object. I believed 
>>>> that if the lag was to small the snapshot would be refreshed, and my 
>>>> object updated, but this didn´t happened.
>>>
>>>
>>> Well, here's a stab at explaining what's going on. The 'lag' you've 
>>> set refers to seconds (or ms, I forget, but time) _before the 
>>> creation_ of the EOEditingContext. If you've set it to 1 second, that 
>>> means that EC will make sure not to use snapshots OLDER than 1 second 
>>> BEFORE the EC was CREATED.  So changes that occured AFTER the EC was 
>>> created----these don't disturb the EC's commitment to not using 
>>> snapshots older than 1 second before it was created.
>>> Now you could constantly reset the EOEditingContext's 
>>> fetchTimestamp(). Note that the static method is called default 
>>> timestamp LAG and means that each EC, upon creation, will have it's 
>>> timestamp set to that much time earlier. But the instance method that 
>>> applies to a particular EOEditingContext is called 
>>> setFetchTimestamp(), and takes an NSTimestamp point-in-time---it's 
>>> not a lag, it's an actual point-in-time, and the EC will refuse to 
>>> accept snapshots prior to this point in time.  So you could be 
>>> constantly resetting this fetchTimestamp to be just a few seconds 
>>> before NOW.  I'm not sure what effect this will have---it could be 
>>> deleterious on efficiency, as in-memory EOs are constantly refetched 
>>> because they're snapshots are no good. Alternately, it might not even 
>>> do what you want: I suspect it only effects _fetches_, it won't 
>>> effect EOs in memory, possibly unless you refetch those EOs. But you 
>>> say you are doing a refetch, so it might have the consequences you 
>>> want.  In fact, this might be a very good idea, but I'm not really 
>>> sure, it makes me a little bit nervous.
>>> Alternately, you always have available to you: setting 
>>> refreshesRefetchedObjects to true on a particular 
>>> EOFetchSpecification. This means, regardless of the timestamp on the 
>>> EC, when you do this fetch, take the fresh values from the db and use 
>>> them to create a new snapshot.  It applies to just that one fetch 
>>> spec, and the timestamp set on the EC doesn't matter at all.
>>> Hope this helps,
>>> --Jonathan
>>>
>>>> Any clue?????
>>>>
>>>> thanks
>>>>
>>>>
>>>> Ing. Gaston Blanco
>>>> __________________________________________________
>>>>
>>>> Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - 
>>>> http://webmail.ciudad.com.ar
>>>>
>>>> Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software 
>>>> para actualizar tu PC.
>>>> http://www.ciudad.com.ar/ar/servicios/ie/
>>>>
>>>> _______________________________________________
>>>> EOF mailing list
>>>> [email protected]
>>>> http://www.omnigroup.com/mailman/listinfo/eof
>>>
>>>
>>> _______________________________________________
>>> EOF mailing list
>>> [email protected]
>>> http://www.omnigroup.com/mailman/listinfo/eof
>>
>>
>>
>> -- 
>>
>> Chuck Hill                                 [email protected]
>> Global Village Consulting Inc.             http://www.global-village.net
>>
>>
>>
> 
> 


-- 

Chuck Hill                                 [email protected]
Global Village Consulting Inc.             http://www.global-village.net