djveremix / redis

Automatically exported from code.google.com/p/redis
0 stars 0 forks source link

WATCH doesn't work correctly on expired keys #270

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

set foo 3
bar
+OK
watch foo
+OK
expire foo 1
:1
# ...wait a second here...
multi
+OK
exec
*0

What is the expected output? What do you see instead?

Expected result is *-1. The similar example w/o EXPIRE which works well:
set foo 3
bar
+OK
watch foo
+OK
del foo
:1
multi
+OK
exec
*-1

What version of the product are you using? On what operating system?

commit b8b8501d, GNU/Linux 2.6.32.

Original issue reported on code.google.com by maxim.vu...@gmail.com on 3 Jul 2010 at 7:05

GoogleCodeExporter commented 8 years ago
I think this is a fix: 
http://github.com/djanowski/redis/commit/de1ca16483f345ed494213c54da9fa5a4080f71
0

Original comment by damian.j...@gmail.com on 3 Jul 2010 at 11:28

GoogleCodeExporter commented 8 years ago
Sorry, re-applied with the latest changes in master: 
http://github.com/djanowski/redis/commit/35dcc0498a1c9d389fd96e7e35833470a529d01
d

Original comment by damian.j...@gmail.com on 4 Jul 2010 at 1:11

GoogleCodeExporter commented 8 years ago
Damian, will it go to the upstream?

Original comment by maxim.vu...@gmail.com on 4 Jul 2010 at 8:57

GoogleCodeExporter commented 8 years ago
Actually, no :-)

Just discussed with Salvatore. There are two different issues in your report: 
one is whether calling EXPIRE on a key 'touches' it for WATCH, and the other is 
whether the server does the same thing when expiring the key. Salvatore 
explained that the first case is valid and will be changed, while the second is 
not valid as it would provide a semantic not available without WATCH (ie the 
ability to somehow 'mark' a volatile key for later use).

So this will work:

SET foo bar
WATCH foo
EXPIRE foo 1
# no need to wait
MULTI
EXEC
-> nil

But this will work as it does today:

SET foo bar
EXPIRE foo 1
WATCH foo
# sleep 2
MULTI
EXEC
-> []

Hope that makes sense.

http://github.com/antirez/redis/commit/b7a8daef6070816e08438fd64b2b9a41571eb333

Original comment by damian.j...@gmail.com on 5 Jul 2010 at 5:54

GoogleCodeExporter commented 8 years ago
Thank you for that fix and explanation!

As i understood, WATCH guards against any user's touches only. Then WATCH 
description (MultiExecCommand wiki page) should be corrected i guess; current 
'It is a command that will make the EXEC conditional: we are asking Redis to 
perform the transaction only if all the values WATCHed *are still the same*' 
appears not true.

Original comment by maxim.vu...@gmail.com on 6 Jul 2010 at 4:59

GoogleCodeExporter commented 8 years ago
This is a good point actually... it should be specified that there is this 
exception.

Original comment by anti...@gmail.com on 6 Jul 2010 at 5:13

GoogleCodeExporter commented 8 years ago
Documentation updated.

Original comment by damian.j...@gmail.com on 6 Jul 2010 at 5:46

GoogleCodeExporter commented 8 years ago
Good job, thanks guys.

Original comment by maxim.vu...@gmail.com on 6 Jul 2010 at 5:51

GoogleCodeExporter commented 8 years ago
http://redis.io/commands/watch#comment-1072598159 calims this behavior has 
changed. Is this true?

Original comment by stu...@testtrack4.com on 4 Dec 2013 at 11:17