"Set" and then "get" don't retrieve the stored value

[Kristian Hellquist]

The problem is that the the small window unfortunately seems to be
quite large for me. Do you have measure in time of how small the
window is?

Basically, I have some unit tests on a web application. The web
application relies on memcached heavily. Everything with memcached has
worked like a charm for us so far. We cache sql-finders in memcached
and invalidates the sql-finders when the model has changed.

In a specific use-case we dont want to update the state of the db
immediately. This data change *a lot*. So when the state of model
change we will cache the sql-finder in memcache directly and later on
we flush the change to the db.  It is in this use-case that I have
experienced the "set" and "get" problem.

My unit-test successfully ran when I added a sleep call of 0.3 s
between each memcache-call :/ This is a lot. Is there a way of
configurate memcached so I experience greater performance?

I know that the test-environment doesnt mimick the user behavior of
the webapplication in real use. We use rails and the unit tests
doensn't involve the webserver at all. So in real life more delay will
be inserted between each "set" and "get" call. But, can I *trust*
memcache that data has been stored if I receive a "STORED" response?
Is just a matter of time before the value can be retrieved again? Or
is it bad usage of memcache to cache the sql-finders directly and
later on update the db?

Thanks for your reply,
Kristian Hellquist


2006/11/14, Jehiah Czebotar <jehiah at gmail.com>:
> > Basically, yes.  There is a small window where this can happen.  There
> > have been numerous discussions about it on the list.  Most people note
> > it with a set and then delete.
> >
>
> tif my memory serves me, the correct order is a delete, set, then a
> get all for the same key
>