Why are you putting an expiry on a key you are incrementing and decrementing? I cant think of a situation where I would want to expire a counter (other then letting it fall out the LRU).
In fact, the only situation I can think of that could use an expiry would follow the way it currently works. Ie, I'd set a key with a 5 minute expiry, and then keep incrementing it for whatever reason, and then after 5 minutes, the key goes away and I create another one. I do this for tracking surges of hits from particular IP's (although I dont use 5 minutes). I cant think of any reason where I would want to give the key a new expiry that couldn't be taken care of by the LRU evictions. On Fri, Sep 11, 2009 at 1:20 AM, Adam Lee <[email protected]> wrote: > > On Thu, Sep 10, 2009 at 9:31 AM, Dean Michael Berris > <[email protected]> wrote: > > > > Hi Guys, > > > > I recently checked the documentation about the memcached protocol and > > while looking at supporting it in my C++ client, I'm looking at a > > situation where I'm not sure whether it's possible to set the > > expiration of a key through the incr/decr commands. From the > > documentation, it seems that there's only a way to increment and > > decrement, but not set the expiration of the key being > > incremented/decremented. > > > > Is this by design? Should I file for a feature request for an > > incr/decr that also updates the expiration of a cache key? > > > > This feature would be really useful for tracking keys -- maybe > > tracking activity within a certain period of time. So something like > > this algorithm would be easily supported: > > > > 1. The first time something happens, set a key to 0 in memcached, > > expires in X seconds > > 2. The next time something happens, increment the key (update the > > expiration to X seconds) -- if the increment fails, that means the key > > has expired, set the key to 0 again > > 3. If the incremented value is higher than a certain number, then > > you can do something about it (maybe there's abusive behaviour going > > on, maybe a clicker bot or something) > > We use this exact functionality, with one key difference-- we set this > expiration when we initialize the counter, but it doesn't get updated > when we incr/decr. This is useful to implement any sort of counter-- > rate limiting certain user actions, tracking occurrences of specific > activities, etc... > > We ended up just building a generic McCounter class that you > initialize with an expiration. It has get/set/incr/decr and takes > care of all the behind-the-scenes work to make sure that the value > exists in MC before trying to incr, etc. It's a super simple class > and has proved infinitely useful-- perhaps you also want to build > something along these lines. > > -- > awl > -- "Be excellent to each other"
