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. 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/yoda%40schli.ch >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
