memcached counters missing in action

[Greg Whalin]

No, the incr/decr calls will return -1 when the object is not found in
cache.  I am somewhat confused by your line of questioning.  Are you
assuming that setting an expiration will ensure that the object lives in
cache for that duration?  That is not what an expiration does.  Setting
an expiration ensures that the object will NOT live in cache past the
expire.  It makes no promises that the object will be there until the
expiration.

gw

Charlie Spurr wrote:
> Bummer...
> 
> So, if I understand what's been said so far, I have to call
> getCounter prior to every decr call to see if the counter is
> still in the cache. If it's not in the cache reload it using
> storeCounter and then I can call the decr method.
> 
> Is that right?
> 
> _Charlie
> 
> 
> On Mar 24, 2006, at 3:23 PM, Greg Whalin wrote:
> 
>> Nope, that won't work.  That will store a serialized Long(1000) object
>> to the cache.  Calling incr() or decr() on it will reset it to 0
>> (according to the api docs).
>>
>> Charlie Spurr wrote:
>>> Greg,
>>> Yes, I would like to set an expiration time on counters so
>>> please add that to the queue for improvements for the Java
>>> client.
>>>
>>> In the meantime, would this work...
>>> Long balance = new Long(10000);
>>> MemCachedClient = MemCachedClient();
>>> client.set("Balance1", balance, expireDate);
>>> client.decr("Balance1", 50);
>>> client.getCounter("Balance1");
>>>
>>> or would I have to use (Long)client.get("Balance1");
>>> instead of getCounter?
>>>
>>> _Charlie
>