"Iteratable" keys in memcache?

[Brad Fitzpatrick]

Yes, and documented as such, iirc.  (At least in the Perl docs)


On Tue, 2 Aug 2005, 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.
>
>