SETNX should have functionality to clear the key on disconnect

[Jan Kohlhof]

Hello,

I recently made up a patch for SETNX and added a third optional param
(see
https://github.com/0x20h/redis/compare/2.6...setnx-delete-on-disconnect).
Providing this param will register KEY to be automatically deleted when
the client disconnects,
given KEY was set successfully. This feature would adapt the semantics
of mysql's get_lock functionality
(named locks acquired by get_lock will be released when the connection
closes).

I think this feature would be pretty useful for several reasons:
- reduce chances of deadlocks (e.g. your script dies or there is an
error so the lock is not released)
- ability to lock until the very end of the script (e.g. PHPs shutdown
functions)
- ability to lock without solely relying on an explicit timeout. The
timeout approach obviously has several disadvantages.
- outstand mysql functionality as get_lock is limited to one lock per
connection. Any further lock would release the former.

Any comments?

best regards
Jan

[Salvatore Sanfilippo]

Hey, just to say that this patch is not going to be merged as I
believe the current 2.6 command set + scripting is enough to model
this use case without connection-dependent behaviors.

Cheers,
Salvatore

On Wed, Nov 21, 2012 at 4:22 PM, Vlad Alexandru Ionescu
<vlad.alexan...@gmail.com> wrote:
>
> Hey Jan,
>
> This looks really interesting. My use case for something like this is using
> Redis to check which backend server would be available to handle stuff. If a
> backend server dies, it would disconnect and its entry would be
> automatically removed from Redis.
>
> Have you tested your patch in production so far?
>
> Cheers,
> Vlad.

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/VjKhcdZKpAEJ.
>
> 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.



--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter

[Vlad Alexandru Ionescu]

Hey antirez, thanks for you reply.

Can you elaborate a little how to model that with SET + scripting?

I don't know how to do that without connection-dependent behavior.

But to make my use case possible in a general manner, I would imagine adding a feature to be able to run an arbitrary command (or even a script) automatically on client disconnection.

Cheers,

Vlad.

[Jeremy Zawodny]

Its too bad--this is one of the key features that ZooKeeper provides (they're called "ephemeral nodes") and I've wished there was a built-in way to do this in Redis.

My 2 cents...

Jeremy

[tjuer]

IMHO, it's not a good idea to depend on this feature for failure detection.

 

Because it's not always that a disconnection can be detected by server. This is limited by TCP protocol itself(unless you open keep_live option )

 

 

tjuer

------------------ Original ------------------

From:  "Vlad Alexandru Ionescu"<vlad.alexan...@gmail.com>;

Date:  Wed, Nov 21, 2012 11:22 PM

To:  "redis-db"<redi...@googlegroups.com>;

Subject:  Re: SETNX should have functionality to clear the key on disconnect

[Salvatore Sanfilippo]

Vlad, in your use case I think that the best option is an heartbeat
alike system. Basically the fact that a TCP socket is open says very
little about the real availability of systems.

In this case actually scripting is not useful, the simplest thing to
do is something like this. Every 5 seconds do:

SET my_id current_unix_time
EXPIRE my_id 10

or alike, so if you don't ping me for more than 10 seconds my key
disappear and I'm no longer available.
But in this case the system that is trying to communicate its
availability is forced to do an action, so if it is busy-looping and
is actually not available will not be able to ping the Redis server.
While the TCP connection may still be alive.

Cheers,
Salvatore

On Wed, Nov 21, 2012 at 10:02 PM, Vlad Alexandru Ionescu

[Salvatore Sanfilippo]

Jeremy, thanks for sharing your point of view, if we have a solid use
case we can start considering such an addition, but so far the
experience with replication, expires, scripting, shows that every time
we add a feature like this, it may interact with the other features in
funny ways, so semantically it would be cool to stop adding things to
Redis or reduce the additions only to things really needed.

This does not mean of course to stop building on what we have, but
while for instance a new bit operation is essentially a self-contained
feature, things like "do this when connection does that" may be more
complex to handle.
The implementation itself of "exec a script on exec" is simple btw,
something like "ATEXIT <script>" that registers just a string that is
called when the client closes the connection, but the script can be
killed because of multiple events and it is not always clear when it
is appropriate to run a script or not.

Btw let's suppose for a moment that it's trivial :-) I wonder what are
the use cases for this feature on ZooKeeper. Thanks!

Salvatore

[Vlad Alexandru Ionescu]

Salvatore, thanks for your reply - that's probably what I'll end up doing.

Cheers,

Vlad.

[shenxiu zhong]

It's useful for distrute lock