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 (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/yoda%40schli.ch >>> >>> This email sent to y...@schli.ch >> >> _______________________________________________ >> 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/mschrag%40mdimension.com >> >> This email sent to msch...@mdimension.com > > _______________________________________________ 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
