Re: Bug in WO5.4.3? (was: Snapshots mysteriously vanishing?)
Re: Bug in WO5.4.3? (was: Snapshots mysteriously vanishing?)
- Subject: Re: Bug in WO5.4.3? (was: Snapshots mysteriously vanishing?)
- From: Marc Guenther <email@hidden>
- Date: Thu, 25 Mar 2010 23:51:49 +0100
Hi,
On 25.03.2010, at 20:44, Mike Schrag wrote:
> it certainly seems fragile, but in practice, i think it's right ... any time you register a new snapshot, it would push into the fast hash (and reset the value). any time you fast hash remove, it would remove the backing snapshot also.
No, that's what it doesn't. It removes the value, but it doesn't check that that value actually belonged to the key it was asked to remove. It needs to check for _lastGID == gid before doing that _lastRec = null. Effectively what it does at the moment, when you tell it to remove gid, it also temporarily removes _lastGID.
It's the user of the class who has to make sure that _lastGID == gid by explicitely calling get(gid) before remove(gid). That's a quite unstable contract I think. Of course, EODatabase adheres to this, but who knows who else is calling these underscore methods.
But, as I said, this is unfortunately not the problem we experience, and it seems to work, so it probably doesn't matter. That other bug sounds much more like the one we see, I have to look into that tomorrow.
Thanks,
Marc
PS: I wouldn't know why, but for some reason I always typed git instead of gid. How strange...
> so the only real window of failure would be if you managed to have a fast GID set, a null fast hash rec, but a non-null snapshot in the dictionary. the rest of the API seems to effectively prevent this scenario, so what this is really providing is fast "cache-the-negative" support -- EODatabase can bypass a dictionary lookup into the snapshot dictionary if you're asking for a snapshot that was just removed.
>
> now, if you're not careful in subclassing this class, you might be able to break this contract, but if you're subclassing EODatabase, you're probably comfortable being careful.
>
> ms
>
> On Mar 25, 2010, at 3:25 PM, Marc Guenther wrote:
>
>> I just digged around in EODatabase, and found the following graphic.
>>
>> This is basically a wrapper around the _snapshots dictionary, which caches the last accessed key/value for speed reasons.
>>
>> But the _fastHashRemove() method seems to be wrong. It doesn't set _lastGID to null. This means, I could insert(valueA, keyA), then remove(keyB) and then get(keyA) would return null instead of valueA?
>>
>> What am I missing here? In EODatabase, a remove() is always called after a get() of the same key, which is the only scenario tgat works. Still, sounds dangerous to me, just to save a single assignment, and these messages are protected not private.
>>
>> Anyway, this is not my original problem, as the missing snapshot really was missing from the _snapshots dictionary.
>>
>> Marc
>> <EODatabase.png>
>>
>>
>> On 25.03.2010, at 18:24, Marc Guenther wrote:
>>
>>> Hi,
>>>
>>> we have switched to WO 5.4.3 (from 5.2.3) several months ago. And since that time, we sporadically experience strange exceptions, mostly NullPointerExceptions deep within EOF, most of which could be traced back to a snapshot mysteriously vanishing.
>>>
>>> I had this in the debugger once, and drilled down to all the snapshots in the EODatabase, and there was one entry missing. Interestingly, this was from an entity which is readonly and cached, and also that entry had to have been there before, otherwise the app wouldn't have gotten to the point where it failed. I checked the DB and the value was there. It is from a table which is only used for lookup and never changes.
>>>
>>> This also happened with other snapshots of regular entitites, and we have never really been able to reproduce it reliably. It seems to happen when lots of ECs are involved, but that's only an assumption.
>>>
>>> Has anyone ever seen something like this? Can this be related to the WO 5.4.3 switch? I remember some talk about open bugs in 5.4.3, but haven't been able to find anything substantial about it.
>>>
>>> Btw, no WOnder (yet, sniff)
>>>
>>> Thanks,
>>> Marc
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden