Issue 614 in redis: [Feature Request] SetNxEx (Set if Not Exists + Expire at the same time)

[re...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 614 by Baptiste...@gmail.com: [Feature Request] SetNxEx (Set if
Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

Hello,

I was wondering if it could be possible to add a new command SetNXEx as
described in my summary. Which allows client to set a key with an expiry
(like SetEx) only if the key does not exist ?
I know that in older versions it wasn't possible and even try to perform a
SetNx command on a key with expiry could failed (before 2.2.x).

I'm not completly aware of all problems that would result, but when I had a
look to the 2.2.0 code, I saw that SetNxCommand is calling the
setGenericCommand with nx = 1 and expire = NULL.
Besides, SetExCommand is calling the setGenericCommand with nx = 0 and
expire != NULL.

As a neophyte of Redis code ... I'm just asking if it is possible to merge
them together to create the new SetNxExCommand ?

Regards !

[re...@googlecode.com]

Comment #1 on issue 614 by didier...@gmail.com: [Feature Request] SetNxEx

(Set if Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

Why not use a "setnx" command, check the result, and then
optionally call "expire" instead?

If you are concerned by the extra roundtrip, it will be
solved by Lua scripting support. I doubt that new commands
that could be implemented as a script will be added at
this stage.

Regards,
Didier.

[re...@googlecode.com]

Comment #2 on issue 614 by Baptiste...@gmail.com: [Feature Request] SetNxEx

(Set if Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

As you said, there is an extra roundtrip which could be a significant
overhead but also make the operation non-atomic.

Lua scripting support could be a solution, but to my mind, the "SetNxEx" is
useful enough to be parts of Redis command list if possible. Scripting is
good, but should be used for exceptional/custom use only; especially if the
implementation of the method just need to call an existing function with
differents parameters.

Regards,
Baptiste.

[re...@googlecode.com]

Comment #3 on issue 614 by jordi...@gmail.com: [Feature Request] SetNxEx

(Set if Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

I would find this feature very useful too. The beauty of it is that is a
very elegant way to handle locks. You just need to to execute setnxex and
check the return value to know if you acquired the lock. The need to use 2
calls (setnx and expire) could cause the client to die in the middle of
those causing a deadlock.

[re...@googlecode.com]

Comment #4 on issue 614 by Baptiste...@gmail.com: [Feature Request] SetNxEx

(Set if Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

@jordi: In fact, as Didier told me, the new LUA scripting feature (2.6.0)
provides a way to avoid this case.

@All: But!! The LUA solution is a client solution, which needs to implement
the script ... compute the SHA1 in memory and to increase performance keep
it in memory.

The Redis philosophy is to keep the API simple ... to my mind, forcing all
client developers to write their own version of the SETNXEX implementation
is not what common people call "a simple API".

I already tried -successfuly- to modify Redis sources to add the SETNXEX
and PSETNXEX commands to the API, it's only 10 lines of code per commands
-including the redis-cli help-.
Since it uses the existing "atomic" implementation for SETEX and SETNX, its
pretty simple to test it and ensure that it works. My only regrets is that
I'll have to maintains my fix/hack in the Redis code until Antirez or
someone e

It could be very nice if this feature (+ its precision version) could be
shipped within the 2.6.0 incoming version.

P.S.: The SETX and PSETX methods could be something good too, but 4 new
methods could be too much to ask, and I think SETNXEX and SET

[Felix Gallo]

Locking is important enough, and common enough, that primitive support should be included, especially if the implementation is as simple and straightforward as it appears to be.  Most serious uses of redis eventually need locking, and locking is hard to get right and easy to mess up badly.

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[re...@googlecode.com]

Comment #5 on issue 614 by alexey.p...@gmail.com: [Feature Request] SetNxEx

(Set if Not Exists + Expire at the same time)
http://code.google.com/p/redis/issues/detail?id=614

Related issue: https://github.com/antirez/redis/issues/428