Why would another client get the wrong data if the original data was
successfully uploaded?

I don't understand the use case, and it's not possible either way.

On Wed, 3 Sep 2014, Xingui Shi wrote:

> what i meant is the data is successfully uploaded, but the client restart for 
> some reason. the data stored in memcache server need to be flushed.
> or other client my get the wrong data.
>
> 在 2014年9月3日星期三UTC+8下午3时04分59秒,Dormando写道:
>       If a client is uploading something and it does not complete the upload,
>       the data will be dropped.
>
>       Otherwise, no.
>
>       On Wed, 3 Sep 2014, Xingui Shi wrote:
>
>       > Hi,  Is there any way to drop data add by a client when the client 
> aborted or exit normally?
>       >
>       > thanks.
>       >
>       > 在 2014年8月12日星期二UTC+8上午10时25分43秒,Dormando写道:
>       >
>       >       > Hello there,
>       >       > There he has a method to be able to remove items from the 
> cache using a regular expression on the key. For example we want to
>       remove
>       >       all the key as "my_key_ *?"
>       >       > We try to parse all the slabs with the command "stats 
> cachedump" but our slabs contain several pages and it is impossible to
>       recover
>       >       all the elements!
>       >       > Thank you.
>       >       >
>       >
>       >       Hi,
>       >
>       >       The common way to do this, instantly, and atomically across 
> your entire
>       >       memcached cluster is via namespacing:
>       >       
> http://code.google.com/p/memcached/wiki/NewProgrammingTricks#Namespacing
>       >
>       >       You take a tradeoff: before I look up my key, I fetch a side 
> key which
>       >       contains the current prefix. Then I add that prefix to my 
> normal key and
>       >       do the lookup. When you want to invalidate all keys with the 
> same prefix,
>       >       you incr or otherwise update the prefix. The old keys will fall 
> out of the
>       >       LRU and your clients will no longer access them.
>       >
>       >       This is *much* more efficient than any wrangling around with 
> scanning and
>       >       parsing keys. That only gets worse as you get a larger cluster, 
> while
>       >       namespacing stays at a consistent speed.
>       >
>       >       Does this match what you're looking for, or did you have some 
> specific
>       >       requirements? If so, please give more detail for your problem.
>       >
>       > --
>       >
>       > ---
>       > You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>       > To unsubscribe from this group and stop receiving emails from it, 
> send an email to memcached+...@googlegroups.com.
>       > For more options, visit https://groups.google.com/d/optout.
>       >
>       >
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to