another one weirdness
Fri, 9 Apr 2004 10:43:20 +0400
On Thu, 8 Apr 2004 11:15:17 -0700 (PDT)
Brad Fitzpatrick <firstname.lastname@example.org> wrote:
> It's because the flush_all just sets the "flush time", and then a new item
> is stored in the same second, then a subsequent "get" finds the item and
> sees it was created <= flush_time, therefore ignores it.
> Which is arguably safer behavior.
Sounds reasonable, but still confusing.
Maybe it's worth to add some flag "this-record-can-be-safely-replaced" (that's what Avva just told, as I understand).
In this case flush_all will mark the records as obsolete, but subsequent replace/set will take away this mark.
IMHO making granularity higher you will encounter the same problem after a while, there is no chance to make it unachievable high..
> My knee-jerk answer: it's a cache for christ's sake... you're supposed to
> deal with empty answers. The current behavior is fine.
Yeah, I know, that I can't rely on the cache, but I just want to clear up these things.
> But the better answer: higher granularity.
Yep, this answer is better =)
But is it really the best?
Antony Dovgal aka tony2001
email@example.com || firstname.lastname@example.org