Is expiration set in transaction guaranteed to be atomic?

278 views
Skip to first unread message

Victor Efimov

unread,
Jul 1, 2014, 5:56:33 AM7/1/14
to redi...@googlegroups.com

if I do

MULTI
SET mykey1 1 EX 3600
# 10 sec delay
SET mykey2 2 EX 3600
EXEC

then

TTL mykey1
# no delay
TTL mykey2

return same expire time for keys. so it looks expiration set at time when transaction executed (well, I expected this).

Question is - is this guaranteed that keys set to same timeout inside MULTI/EXEC will either both exist (not expired) or
both not exist (expired) ? or it's possible that at some moment of time mykey1 is still exists and mykey2 already not exists
(or mykey2 exists and mykey1 not exists)?

If yes, could this be documented? If no could this be implemented (to implement this probably need to remember time when transaction executed and use it inside transaction)?

Also, if "yes"

MULTI
# use of mykey1
# very long set of commands
# use of mykey2
EXEC

Will use "mykey2" use time of transaction begin to determine key expiration or a real time ?

Jan-Erik Rediger

unread,
Jul 1, 2014, 6:42:19 AM7/1/14
to redi...@googlegroups.com
Commands in a MULTI/EXEC transaction are only executed once EXEC is
sent. This is documented in the transactions page
(http://redis.io/topics/transactions):

> All the commands are executed once EXEC is called.

Before that they are appended to an internal queue. Any delay between
adding commands before EXEC is irrelevant for the actual execution.

Apart from that, each command makes a call to `mstime()` to get the
actual time and then adds your passed value. As functions take far less
than 1s the keys should be expired at the same time (in the boundaries
of these small function call differences).

Does this help?
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/redis-db.
> For more options, visit https://groups.google.com/d/optout.

Victor Efimov

unread,
Jul 1, 2014, 12:23:08 PM7/1/14
to redi...@googlegroups.com, jan...@fnordig.de


вторник, 1 июля 2014 г., 14:42:19 UTC+4 пользователь Jan-Erik Rediger написал:
Commands in a MULTI/EXEC transaction are only executed once EXEC is
sent. This is documented in the transactions page
(http://redis.io/topics/transactions):

> All the commands are executed once EXEC is called.

Before that they are appended to an internal queue. Any delay between
adding commands before EXEC is irrelevant for the actual execution.

Apart from that, each command makes a call to `mstime()` to get the
actual time and then adds your passed value. As functions take far less
than 1s the keys should be expired at the same time (in the boundaries
of these small function call differences).

ok. so, each command makes separate call to mstime(), so there is small chance that


SET mykey1 1 EX 3600
will be executed when system time is N
and next command in transaction
SET mykey2 1 EX 3600
will be executed when system time is N+1
even if delay between those commands is N/1000000



Does this help?

Thank you. Wouldn't it be better if mstime() taken before transaction block, just once. This will guarantee keys expired at same moment.
 

Alexey Shuksto

unread,
Jul 2, 2014, 1:26:34 AM7/2/14
to redi...@googlegroups.com, jan...@fnordig.de
You can use EXPIREAT intead of SET EX/EXPIRE:

MULTI
SET mykey1 1
EXPIREAT unix_time_seconds
SET mykey2 1
EXPIREAT same_unix_time

вторник, 1 июля 2014 г., 20:23:08 UTC+4 пользователь Victor Efimov написал:

Victor Efimov

unread,
Jul 2, 2014, 6:33:10 AM7/2/14
to redi...@googlegroups.com, jan...@fnordig.de
 Indeed, that solves my issue! Thank you!
Reply all
Reply to author
Forward
0 new messages