Hey,
We might be adding a 'touch' command in a future release, but as of now
there's no way to do that.
If you really need second granularity, you won't have much luck. If you
can chunk it out so the key only needs to resync every 5 minutes or less,
the overhead of re-setting it, or CAS-updating a soft limit, isn't as bad.
-Dormando
On Fri, 2 Oct 2009, Bill Moseley wrote:
> I suspect asking this means my usage is wrong, but here goes.
>
> There's no way to "touch" a cached entry to update the expires time, correct?
>
> So, I have a pretty large item cached. It's mostly read only. It has an
> expires time, but every time it's read (or written) I want to extend the
> expires time. Basically I want an inactivity time out
> on the cached item -- keep it in the cache as long as it's being used within
> a time period.
>
> I can write the item back to memcached each time, but that seems a bit of a
> waste if the item does not change (and it's large).
>
> Or I can avoid setting an expires on the item itself and have a separate
> second item that is just used to expire the item. Trade off here is I'm
> doing an extra memcached access
> each time.
>
> if ( get( expires_key ) ) {
> item = get( key );
> set( expires_key, 1, expires_seconds );
> }
> else {
> item = fetch_item();
> set( key, item );
> set( expires_key, 1, expires_seconds );
> }
>
> That's not exactly correct. In this specific case that fetch_item() requires
> re-authorization for the item, but that's not really pertinent.
>
>
> Does it matter that the item doesn't have an expires time in this case? Or
> is there any reason to set a very long expires on the item and a short
> expires on the cache item that tracks the real expires
> time?
>
> IIRC, memcached will toss out "expired" items first, then items w/o an
> expires time when memory is needed. Are there stats that will show the
> difference?
>
>
> Thanks,
>
>
> --
> Bill Moseley
> [email protected]
>
>
