"Iteratable" keys in memcache?

[Elizabeth Mattijsen]

Since memcached is unthreaded and only executes 
one command at a time, the answer would be yes, 
in my opinion.

At 11:36 AM -0400 8/2/05, Christopher Gillett wrote:
>Oh duh...are incr and decr operations atomic? 
>
>
>From: memcached-bounces at lists.danga.com 
>[mailto:memcached-bounces at lists.danga.com] On 
>Behalf Of Christopher Gillett
>Sent: Tuesday, August 02, 2005 11:18 AM
>To: memcached at lists.danga.com
>Subject: "Iteratable" keys in memcache?
>
>
>I'm building an application that needs to run 
>quickly.  My plan is to use memcache to store 
>state dataŠsince the state data can be recreated 
>if needed, and since the application needs to 
>run quickly, I am planning on not using a 
>database as a backing store.  I'm looking for 
>some way to create unique keys that I can use to 
>iterate over the cache entries - much like a row 
>number or an auto-increment id in a database. 
>Is there any functionality in memcache or 
>elsewhere that I can use to create guarenteed 
>unique keys that of an iteratable form?  I don't 
>see global or cache-entry specific 
>lock()/unlock() in memcache, so I'm wondering if 
>there's a way to solve this within memcache.
>
>There will be many resources trying to create 
>cache entries while my application is active, so 
>I'm looking for  sort of guarenteed atomic 
>operation.  Something like:
>
>                 value = cache.get("the next row id")
>                 value +=1
>                 cache.set("the next row id", value)
>
>won't work because another running instance 
>could produce the same value at the same time.
>
>If there's no support for something like this, 
>is there any interest in an "atomic increment" 
>function for memcache?  I'd be willing to dig 
>into it if there is a broader need.
>
>Any thoughts?
>
>Thanks,
>Chris
>
>---
>Christopher Gillett
>Compete, Inc.