what guarantees can i expect from write ops?

[Richard 'toast' Russo]

Paul,

That's a pretty small expiretime (1 second).  If I recall correctly,
memcached uses a unixtime for expiration, so it's possible your set
comes before the second jumps and the get after.

Also, if your server is under (really) heavy use during the testing,
it's possible your cache retention is really bad.

In the memcached is not a database, consistency is not assured camp,
your expectation of getting the same data that you set back is pretty
reasonable.  Doesn't work if some other process is writes to the same
key, the key falls out of the cache, or if your client changes where
it wants to hash that key between the write and the read.

Offloading writes doesn't seem like a safe use of memcached, though. 
Would be interested in the reasoning behind that.


--- Paul G <paul-lists at perforge.com> wrote:

> folks,
> 
> i'm seeing unexpected (by me, naturally ;) results with 1.1.12.
> namely,
> write ops (with the exception of incr/decr for obvious reasons) do
> not
> guarantee that upon return a subsequent read op will see the result
> of the
> write op. although i am using php-mcache, i have patched memcached
> to enable
> a third level of verbosity (-vvv) which shows data passed to add,
> set and
> replace and returned by get and used it to confirm that this is
> indeed
> happening in memcached itself:
> 
> --- start trace (err)
> <8 new client connection
> <8 set TEST:rand1_433c8cac584fd433c8cac5cc7d2 0 1 3
> data:foo
> >8 STORED
> <8 get TEST:rand1_433c8cac584fd433c8cac5cc7d2
> >8 END
> --- end trace
> 
> --- start trace (success)
> <6 new client connection
> <6 set TEST:rand1_433c8ca846ce1433c8ca84c1921 0 1 3
> data:foo
> >6 STORED
> <6 get TEST:rand1_433c8ca846ce1433c8ca84c1921
> data:foo
> >6 sending key TEST:rand1_433c8ca846ce1433c8ca84c1921
> >6 END
> --- end trace
> 
> now, i am *not* expecting atomicity, but i *was* expecting
> sequential
> accesses to have a consistent view of the dataset. is this
> something folks
> here have seen and possibly worked around? i'm going to continue
> reading the
> code to track this down and will post the results here should noone
> chime in
> first, although i am hoping that i won't have to do this (bigger
> fish to fry
> and all that ;).
> 
> any input is appreciated, although i'd like to point out that
> "memcached is
> meant to be backed by a db, use it that way or die" isn't too
> helpful for my
> current intended use since i'm trying to offload db writes.
> 
> -p
> 
> 
>