Using Redis as a cache, with time-to-live?

[John Moore]

I'm using Redis as a simple cache, to allow session sharing across a
number of Java web applications. I want to have keys automatically
expire after 30 minutes of inactivity. Obviously I need to use EXPIRE
after a SET, with a 30 minute timeout. But I don't want the keys to
expire 30 minutes after they're set, but 30 minutes after they're last
used. I imagine I could do this simply by doing an EXPIRE after every
GET as well. But I was wondering whether there was some automatic way
of doing this which I hadn't picked up on, so every call automatically
resets a kind of timer?

[Tim Lossen]

no, there is no other way that i am aware of -- you have to do it
"by hand" after each get.

tim

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>

--
http://tim.lossen.de

[Josiah Carlson]

Three options:
1. Add a piece that automatically adjusts the TTL during GET in your client
2. Use an altered version of the 1-liner I offered before that uses
the redis-cli to MONITOR and send EXPIRE commands (see below)
3. Write your own version of #2 that works with multiple databases,
knows what keys to expire, etc., in a language that can keep up

redis-cli monitor | sed -e 's/"//g;s/(db ..*)//g' | grep GET | awk
'{print "expire", $3, "1800"}' | redis-cli

Regards,
- Josiah

[John Moore]

OK, thanks for the input. Actually, calling EXPIRE after every GET is
no hassle. My only concern was over something like atomicity of
operations, but that's not really important in this case (if process B
sneaks in and sets a half hour expire time on a given key microseconds
before process A does precisely the same, no harm is done).

[Josiah Carlson]

If you need multiple operations to happen essentially simultaneously
WRT Redis, you can wrap that update in a MULTI/EXEC. Incidentally, if
you GET then EXPIRE, you actually have a cute little race condition
where between your GET and EXPIRE, the key could expire. EXPIRE/GET
doesn't have that race.

Regards,
- Josiah

[John Moore]

On Feb 13, 4:57 pm, Josiah Carlson <josiah.carl...@gmail.com> wrote:
> If you need multiple operations to happen essentially simultaneously
> WRT Redis, you can wrap that update in a MULTI/EXEC. Incidentally, if
> you GET then EXPIRE, you actually have a cute little race condition
> where between your GET and EXPIRE, the key could expire. EXPIRE/GET
> doesn't have that race.

Both good points, thanks. I'll swap the calls around and wrap them in
a MULTI/EXEC (assuming such a thing is possible with the Jedis Java
client - I imagine it is).

John

[John Moore]

Just realized that I have a minor problem here. Calling EXPIRE with
GET isn't working - the Redis version is 1.2.6 (from the Debian
repository) and the timeout cannot be overwritten. I'll try and update
the server to a more recent version, but if that is not possible, is
there some other way I can update the timeout?

John

[John Moore]

Forget that, just upgraded to 2.4.2 and the timeout is now changeable.

[Salvatore Sanfilippo]

On Tue, Feb 14, 2012 at 2:30 PM, John Moore <google...@jmsd.co.uk> wrote:

> Forget that, just upgraded to 2.4.2 and the timeout is now changeable.

I suggest upgrading to the latest (2.4.7), and not trusting Linux
distributions for Redis, just get the fresher.

Redis is trivial to install, apt-get install or 'make install' is more
or less the same amount of work.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele