what guarantees can i expect from write ops?

[Paul G]

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